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.