Alternatives to finalization - the fourth child?

[Nick Name]

On Mon, 10 Mar 2003 11:30:01 +0000
Alastair Reid <alastair@reid-consulting-uk.ltd.uk> 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