----- Original Message -----
From: "Paul Prescod" <paulp / ActiveState.com>
> ...there is an issue wherein some apps have a GUI event loop and it
> isn't clear how to integrate the loop over the non-blocking IO with it.

Perhaps Ruby could learn from Tcl/Tk and define a standard event-loop with a
Ruby and C API. Extension writers could then integrate their event handling
with this loop rather than writing their own loop. The event loop API would
handle thread context switching to avoid blocking all threads. This would be
a great help for programmers using multiple extensions and frameworks in the
same application.  On several projects I have had to work out how to
integrate the event loops of different libraries that each want to take
control of the main function.  It would also be a great help for extension
writers if it helped them avoid blocking the process instead of one thread
(for example, Java JNI does not offer any help in this regard and it's a
pain to write code that works with both native and "green" threads).

I expect such an API would have to be layered in some way: the top layer
being platform independent abstractions for the event loop and concrete
event sources (sockets, serial ports, signals, message queues, whatever),
and the bottom layer being a platform-specific API for writing new event
sources and passing them to the event loop (Unix fd's and select calls,
Win32 HANDLEs and MsgWaitForMultipleObject calls, etc.).

Also, the event loop should be optional. It should be dynamically loaded
only if required.  Tcl/Tk integrates the event loop with the standard
libraries too tightly IMHO.

Just a thought...

Cheers,
        Nat.