On Mon, 10 Mar 2003 11:30:01 +0000 Alastair Reid <[EMAIL PROTECTED]> wrote:
> Nick name says that a problem with the first is: > > The problem is that if no memory is allocated, no garbage collection > > happens; of course finalization is not guaranteed, as the manual > > states. > > Haskell code tends to consume memory at a fairly constant rate so, as > long as your program is not blocked waiting for input, you should be > consuming memory. You then need to tweak the configuration of the > garbage collector (+RTS -h... ...-RTS in GHC) to make the GC trigger > at the desired frequency. Ok, today the combination of compilers/libraries I use have *decided* I won't do tests any longer :( === Talking about the "f :: IO [a]" approach On my first test, if I had the program waiting there for events, I didn't see the finalizer at work, even if calling "performGC" ***inside the event handler*** (handling a mouse motion event). I saw the mouse motion handler print and print debug information, but never the finalizer printing that "callback uninstalled". However, calling a "print fib 100" somewhere in my main function shows that finalizers really work sometimes. I see you (the FFI team) have had a very long discussion on finalizers, but I have not the skills to understand it fully. I guess the main problem here is that I am giving up the control of disallocating a resource (the callback) to an entity (the garbage collector) wich cares about a *different* resource, with *different* cost (the memory); however, when the programs is at work, garbage IS collected and so I guess the solution is pretty satisfying in general. === The fourth child ??? Now, I think, if one had a resource wich he really cares about more than memory and threads or timers, and if he was still wishing to give a stream produced with this resource around to threads and pure functions, he could... ... produce a stream with some "unsafeInterleaveIO" operations; each of these operations: 1. checks for the existence of the resource 2. if necessary allocates it 3. anyway, retrigger a timer wich, at timeout, deallocates the resource Step 2 can be replaced with 2'. if the resource doesn't exist, then it's time to return the infamous empty list What do you think of this approach? Have you ever tried it? (of course, with this formulation, in general I guess timeouts are standard practice with scarce resources). And, the timeout can be replaced with "another one wants my resource". And, is it time to reopen that operating systems book? :) Vincenzo _______________________________________________ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe