AnyEvent::Fork failed with sysread filehadle
Genban Tade
tadegenban at gmail.com
Mon Mar 28 07:43:27 CEST 2016
Thank you for your explain. I'm rarely work with I/O stuff
Also: maybe that module isn't actually what you want - there are higher
> level modules that make it easier to communicate with AnyEvent::Fork
> subprocesses, namely AnyEvent::Fork::RPC and AnyEvent::Fork::Pool - they
> deal with this low-level event handling stuff, and thus make it much more
> convenient.
>
I'm using AnyEvent::Fork::Pool now, it seems worked for me.
Makes perfect sense, the filehandle is non-blocking and when there isn't any
> data, you get "Resource temporarily unavailable".
Actually I found a samilar question here, and there is an answer from you
http://stackoverflow.com/questions/27153465/anyeventfork-how-to-wait-for-child/27219603#27219603
which says :
"The sysread will try to read from the child. If the child never sends
anything, this will block the parent until the child exits, as in that
moment, the child will close it's end of the pipe and sysread gets an EOF."
so my question is why my sysread (or maybe filehandle ) will not block the
parent as you said?
Regards
2016-03-27 23:46 GMT+08:00 Marc Lehmann <schmorp at schmorp.de>:
> On Fri, Mar 25, 2016 at 12:28:36AM +0800, Genban Tade <
> tadegenban at gmail.com> wrote:
> > wish to use sysread to detect the child process exit, expect it will
> block
> > until the child exit, but it not, and directly return undef and $! is
> > "Resource temporarily unavailable"
>
> Makes perfect sense, the filehandle is non-blocking and when there isn't
> any
> data, you get "Resource temporarily unavailable".
>
> > I also tried replace sysread with a AE io watcher:
> >
> > this works, and print:
> > parent here
>
> It works, because you read data when there actually is data, not before.
>
> > can you figure out where's wrong in my code?
>
> I suspect that you need to polish up your skills with I/O a bit - have
> you had a look at AnyEvent::Intro, to get into the basics of event-based
> programming?
>
> Also: maybe that module isn't actually what you want - there are higher
> level modules that make it easier to communicate with AnyEvent::Fork
> subprocesses, namely AnyEvent::Fork::RPC and AnyEvent::Fork::Pool - they
> deal with this low-level event handling stuff, and thus make it much more
> convenient.
>
> --
> The choice of a Deliantra, the free code+content
> MORPG
> -----==- _GNU_ http://www.deliantra.net
> ----==-- _ generation
> ---==---(_)__ __ ____ __ Marc Lehmann
> --==---/ / _ \/ // /\ \/ / schmorp at schmorp.de
> -=====/_/_//_/\_,_/ /_/\_\
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.schmorp.de/pipermail/anyevent/attachments/20160328/02faf56b/attachment.html>
More information about the anyevent
mailing list