Re: Re: Events and finalizers

On Mon, Mar 10, 2003 at 09:36:00PM +0100, Nick Name wrote:
> === AN IMPORTANT NOTE ===
> 
> I want to explain better what you just stated: "a callback
>  model also has to have a way of deinstalling the callback".
> 
> If we return, together with the stream, the IO action used to unregister
> the callback, it could easily become of no use if we pass the stream to
> a new thread. We can't then know when that thread finishes to use the
> stream (we could pass the closing action together with the stream,
> anyway), so generally we HAVE to rely on garbage collection and
> finalizers. But this is the same thing of registering a callback wich
> multiplexes events to two threads, and the same issue.
> 
> ====
 Yesterday I thought about callbacks like the "expose" event under Gtk.
This callback has not only a parameter (which could be handled by a
stream) but a return value *and* more constraints: The "expose" callback 
clears the area to be repainted and marks it as update when the callback 
returns (this is called "beginPaint" and "endPaint" under Windows). This 
must be difficult to model with streams or if you spawn threads in a 
callback. I think abstraction here is more subtle in practice and to 
develop a universial solution turns out to be more difficult than 
expected.

Nevertheless, I think streams are nice. Do you think it's possible to 
define the CGA just with events and implement streams on top of it? If it 
can be formulated as separate library, then we don't need to solve all 
these problems right now.

Axel.