Re: Status of Event Driven Network Programming Libraries in 1.9

On Dec 27, 2007 9:33 PM, Paul Brannan <[e-mail]> wrote:
> On Thu, Dec 27, 2007 at 06:41:48PM +0900, hemant wrote:
> > Although EM works well, but any EM app makes so many rb_funcall and
> > rb_thread_schedule() calls that advantage is sometimes lost. I asked
> > ko1 about possibility of having these advanced selectors right there
> > in Ruby itself.
> >
> > He said, he would like to have!
> >
> > With these selectors in core and using fibers, one can write some fast
> > networking application without bothering to delve in C. Ideas?

> By right there in Ruby you mean in the standard library?

It depends upon the implementation. If it has to go in standard
library, it will do same things that other libraries are doing. Thats
to say, making calls to rb_thread_schedule and check for interrupts
and signals.



>
> I think this is a good idea.  It would be cool if the user could plug in his
> own IO multiplexing routines.  Other interpreters (e.g. Tcl) allow the event
> loop to be replaced by setting some function pointers.
>
> For reference, the structure that Tcl uses:
>
>   typedef struct Tcl_NotifierProcs {
>       Tcl_SetTimerProc *setTimerProc;
>       Tcl_WaitForEventProc *waitForEventProc;
>       Tcl_CreateFileHandlerProc *createFileHandlerProc;
>       Tcl_DeleteFileHandlerProc *deleteFileHandlerProc;
>       Tcl_InitNotifierProc *initNotifierProc;
>       Tcl_FinalizeNotifierProc *finalizeNotifierProc;
>       Tcl_AlertNotifierProc *alertNotifierProc;
>       Tcl_ServiceModeHookProc *serviceModeHookProc;
>   } Tcl_NotifierProcs;
>
> I'm not sure what all of these do nor which of them is applicable to Ruby, but
> at least wait for event and the timer should be pluggable.

Well, it would be surely useful. But only core guys can say something
about this!



-- 
Let them talk of their oriental summer climes of everlasting
conservatories; give me the privilege of making my own summer with my
own coals.

http://gnufied.org