Status of Event Driven Network Programming Libraries in 1.9
hemant
Anyone doing serious event driven network programming on *nix will
want to have support for advanced selectors ( epoll, kqueue etcetra )
and bug free non blocking IO, because it scales much better than one
thread per client approach( or a pool if you prefer ).
In Ruby, we have:
http://rubyforge.org/projects/eventmachine/
http://rubyforge.org/projects/shooting-star/
http://rubyforge.org/projects/rev
and pure ruby:
Although shooting-star is not in the same league, but it has epoll,
kqueue support for writing server side network applications. With 1.9
above first two libraries are partly broken.
Their reactor loop is in C and CHECK_INTS, TRAP_BEG macros aren't working.
Reason I am writing this mail is, on #ruby-lang i conveyed this to ko1
and he asked me to report here.
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?
Comments?
--
Let them talk of their oriental summer climes of everlasting
conservatories; give me the privilege of making my own summer with my
own coals.
Jordi
By right there in Ruby you mean in the standard library?
Jordi Polo Carres
Natural language processing laboratory
NAIST
http://www.bahasara.org
Francis Cianfrocca
Hi,
Anyone doing serious event driven network programming on *nix will
want to have support for advanced selectors ( epoll, kqueue etcetra )
and bug free non blocking IO, because it scales much better than one
thread per client approach( or a pool if you prefer ).
In Ruby, we have:
http://rubyforge.org/projects/eventmachine/
http://rubyforge.org/projects/shooting-star/
http://rubyforge.org/projects/rev
and pure ruby:
http://packet.googlecode.com/
EM now supports pure Ruby.
Paul Brannan
> 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?
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.
Paul
hemant
> 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!