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

[Fulko Hew]

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

> On Thu, Nov 21, 2013 at 12:57:49AM -0500, Fulko Hew <fulko.hew at gmail.com>
> wrote:
> > a) it operates backwards to what I was trying to do.
> >    ie. it allows RPCing into child threads, to ask them to be workers.
> >    but what I wanted were workers that allowed RPCing the parent
> >    to retrieve info regarding what the workers need to do,
>
> You can still send events from the worker to the parent to request
> information (via AnyEvent::Fork::RPC::event), so you wouldn't really need
> to redesign, you'd just have to think of ::event as a request, and the
> request sent (in response, by the parent) as delivering the request info.
>

Sorry, my mistake.  I had incorrectly stopped reading

when I saw
the statement about 'no return values'.  But I now understand how
I could use that to implement my scenario.

> > b) I get further with respect to multi-threaded operation, but it looks
> like
> >    the RPC/children of an AnyEvent::Fork application must be
> non-blocking,
> >    as in the
>
> The fact that the default backend actually is blocking is a big hint that
> blocking is fine, don't you think so? :)
>

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 was hoping that a block in the backend wouldn't block 'other' backends.

>       Example 3: Asynchronous backend with Coro
> >
> >    Unfortunately, my children do (must) block, and that breaks this
> > approach.
>
> 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 attached my test code. If you enable Coro sleep, it works, but
if you enable the blocking sleep, each RPC invocation blocks everything.]

... 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.

>    That's why I wanted 'real' forked children.
>
> I feel you are overly negative towards working approaches :)
>

I'm trying not to be. :-(
It may seem that way, only because
I haven't yet been able to achieve what I need.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.schmorp.de/pipermail/anyevent/attachments/20131121/de499394/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: statd_anyeventForkCoro
Type: application/octet-stream
Size: 1400 bytes
Desc: not available
URL: <http://lists.schmorp.de/pipermail/anyevent/attachments/20131121/de499394/attachment.obj>