> 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. Tk thread can block Ruby, since it is a native (or at least non-Ruby) thread. Doing screen updates during processing (i.e. without user interaction) is undoable (the Thread.new {Tk.mainloop} as suggested a few days ago in this list, fails when the user presses a button, because Tk apparently is not sufficiently thread safe). Maybe that's the Ruby/Tk implementation, since you suggest Tcl (what about `wish`?) does not suffer from this problem. I agree that a mechanism for serializing all external events (network, GUI, self-generated events(?)) would be great. PS: freeciv has implemented a serialization on events as well (kbd and network for the server; network and GUI for the client). +--- Kero ------------------------------ kero / chello.nl ---+ | Don't split your mentality without thinking twice | | Proud like a God -- Guano Apes | +--- M38c ------- http://members.chello.nl/~k.vangelder ---+