Eventmachine talk - May 2007 - EM and popen

From: Francis Cianfrocca
>
> > On 4/22/07, Bill Kelly <billk at cts.com> wrote:
> >
> > I don''t understand why it would require any changes to
EM''s
> > core to treat the pipe returned by popen as ''just another
> > eventable file descriptor''?  Looking at em.cpp, we already
> > have the beginnings of event support on nonblocking file
> > descriptors with _OpenFileForWriting.  Why couldn''t the pipe
> > returned by popen be wrapped in a FileStreamDescriptor in
> > the same manner?
> >
> > Rather than requiring changes to EM''s core, it seems like it
> > would fit in quite naturally.  Am I missing something?
>
> You''re probably right. I''m going to try to get to this
today.
> To add a bit to the point about signals: EM should completely
> hide them (and the parallel mechanism on Windows) from user code.
> I think with Twisted you get an event (which is triggered by a
> signal under the covers) that tells you the fork child has ended,
> which is all you really care about, of course.
Hi Francis,

Any progress on the eventable popen?

I''m thinking of trying to add this to EM, myself, so I was
wondering if you may have already made a start on it?

And/or, any thoughts on what the API might look like?  One
of the things I like about popen() in Ruby and Perl, is that
you can get the PID of the child process.

Looking at Ruby''s popen() implementation in io.c, I see that
they''re not using the popen() library call at all; but instead
are using a custom implementation using fork/exec in order
to obtain the PID (I presume.)

Let''s say we added something to the EM ''C'' API, like:

  const char *evma_popen (const char *command, const char *mode);

This would return a binding, and EM would fire the usual
EM_CONNECTION_COMPLETED, _READ, _UNBOUND events.  (Assuming
mode "r" for CONNECTION_READ... If mode were "w", then
presumably
one could use evma_send_data_to_connection() to write to the pipe.
As far as signals like EPIPE, I figure they should just be
converted to CONNECTION_UNBOUND...?)

And then, in terms of the API, how to ask for the PID?  I guess,
in keeping with API calls we already have, like evma_get_peername()
we could add one like:

  int evma_get_pid (const char *binding);

...something like that?

Does this seem reasonable?

I''d really like to have an eventable popen(), and I may give
this a shot when I have time.  (BTW, I don''t know how to make
it work on Windows, since their pipes don''t work with select.)


Regards,

Bill

I''m not seeing anything wrong with this so far, Bill.

I have no problem leaving the implementation a stub on Windows for now at
least.
Let me give it a shot. If I don''t get around to it tonight,
it''s all yours.
Deal?


On 5/29/07, Bill Kelly <billk at cts.com> wrote:
>
>
> From: Francis Cianfrocca
> >
> > > On 4/22/07, Bill Kelly <billk at cts.com> wrote:
> > >
> > > I don''t understand why it would require any changes to
EM''s
> > > core to treat the pipe returned by popen as ''just
another
> > > eventable file descriptor''?  Looking at em.cpp, we
already
> > > have the beginnings of event support on nonblocking file
> > > descriptors with _OpenFileForWriting.  Why couldn''t the
pipe
> > > returned by popen be wrapped in a FileStreamDescriptor in
> > > the same manner?
> > >
> > > Rather than requiring changes to EM''s core, it seems
like it
> > > would fit in quite naturally.  Am I missing something?
> >
> > You''re probably right. I''m going to try to get to
this today.
> > To add a bit to the point about signals: EM should completely
> > hide them (and the parallel mechanism on Windows) from user code.
> > I think with Twisted you get an event (which is triggered by a
> > signal under the covers) that tells you the fork child has ended,
> > which is all you really care about, of course.
>
> Hi Francis,
>
> Any progress on the eventable popen?
>
> I''m thinking of trying to add this to EM, myself, so I was
> wondering if you may have already made a start on it?
>
> And/or, any thoughts on what the API might look like?  One
> of the things I like about popen() in Ruby and Perl, is that
> you can get the PID of the child process.
>
> Looking at Ruby''s popen() implementation in io.c, I see that
> they''re not using the popen() library call at all; but instead
> are using a custom implementation using fork/exec in order
> to obtain the PID (I presume.)
>
> Let''s say we added something to the EM ''C'' API,
like:
>
>   const char *evma_popen (const char *command, const char *mode);
>
> This would return a binding, and EM would fire the usual
> EM_CONNECTION_COMPLETED, _READ, _UNBOUND events.  (Assuming
> mode "r" for CONNECTION_READ... If mode were "w", then
presumably
> one could use evma_send_data_to_connection() to write to the pipe.
> As far as signals like EPIPE, I figure they should just be
> converted to CONNECTION_UNBOUND...?)
>
> And then, in terms of the API, how to ask for the PID?  I guess,
> in keeping with API calls we already have, like evma_get_peername()
> we could add one like:
>
>   int evma_get_pid (const char *binding);
>
> ...something like that?
>
> Does this seem reasonable?
>
> I''d really like to have an eventable popen(), and I may give
> this a shot when I have time.  (BTW, I don''t know how to make
> it work on Windows, since their pipes don''t work with select.)
>
>
> Regards,
>
> Bill
>
>
>
> _______________________________________________
> Eventmachine-talk mailing list
> Eventmachine-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/eventmachine-talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070529/eeea7fd2/attachment.html