how to use AnyEvent::Handle on the child of AnyEvent::Run (aka portable_socketpair)?

Fulko Hew fulko.hew at gmail.com
Thu Nov 21 18:19:31 CET 2013


> The newly attached version (because I now have two separate forked
> children (instead of using async_pool)) works the way I need, just like
the
> Coro timing.

Sorry, I forgot to attach the code.




On Thu, Nov 21, 2013 at 9:36 AM, Marc Lehmann <schmorp at schmorp.de> wrote:

> On Thu, Nov 21, 2013 at 09:16:18AM -0500, Fulko Hew <fulko.hew at gmail.com>
> wrote:
> > Sorry again, but I get confused with which is frontend versus backend.
> > (_I_ think front end is the parent and backend is the child/children
> > where
> >
> > RPC execution takes place.)
>
> I think the same, that's how it is, even :)
>
> > I was hoping that a block in the backend wouldn't block 'other' backends.
>
> I would hope so, too - I wouldn't even know how one child would be able to
> block another child process or the parent.
>
> > > Why do you (wrongly) think that blocking breaks anything? What do you
> > > think breaks when you block?
> >
> > I was expecting, that since the RPC is being executed in a 'forked'
> > environment, that a block in the RPC would not block the parent
> > from issuing another RPC (to effectively another, separate? forked
> > environment).
>
> I expect that, too, and that's also what happens in your example code on
> my system.
>
> > [I attached my test code. If you enable Coro sleep, it works, but
> > if you enable the blocking sleep, each RPC invocation blocks everything.]
>
> I tried your program, but in both cases "calling completed" is printed
> before
> the results come in, so the main program isn't blocked.
>
> If you mean the child gets blocked, well, that's what your code does, and
> that is what you claimed you wanted to have, so I don't think that's what
> you mean.
>
> > ... I also tried creating two AnyEvent::Fork->new()
> > that I hoped would duplicate the child in which to execute
> > the RPC (similar to your Coro::async_pool), but that created
> > even more errors.
>
> You haven't mentioned any errors yet. What do you mean with "more errors"?
>
> With Coro's sleep, I get:
>
>    Thu Nov 21 15:29:33 2013 calling add
>    Thu Nov 21 15:29:33 2013 calling mul
>    Thu Nov 21 15:29:33 2013 calling completed
>    Thu Nov 21 15:29:33 2013 add called
>    Thu Nov 21 15:29:33 2013 mul called
>    Thu Nov 21 15:29:34 2013 mul returning after 1 second sleep
>    mul 1,3 3
>    Thu Nov 21 15:29:34 2013 mul done
>    Thu Nov 21 15:29:36 2013 add returning after 3 second sleep
>    add 1,3 4
>    Thu Nov 21 15:29:36 2013 add done
>
> with perl sleep, I get:
>
>    Thu Nov 21 15:29:54 2013 calling add
>    Thu Nov 21 15:29:54 2013 calling mul
>    Thu Nov 21 15:29:54 2013 calling completed
>    Thu Nov 21 15:29:54 2013 add called
>    Thu Nov 21 15:29:57 2013 add returning after 3 second sleep
>    Thu Nov 21 15:29:57 2013 mul called
>    Thu Nov 21 15:29:58 2013 mul returning after 1 second sleep
>    add 1,3 4
>    Thu Nov 21 15:29:58 2013 add done
>    mul 1,3 3
>    Thu Nov 21 15:29:58 2013 mul done
>
> In both cases the parent wasn't blocked in any way. What output do you
> get?
>
> --
>                 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/20131121/d540f030/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: a
Type: application/octet-stream
Size: 1458 bytes
Desc: not available
URL: <http://lists.schmorp.de/pipermail/anyevent/attachments/20131121/d540f030/attachment.obj>


More information about the anyevent mailing list