<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 21, 2013 at 2:11 AM, Marc Lehmann <span dir="ltr"><<a href="mailto:schmorp@schmorp.de" target="_blank">schmorp@schmorp.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">On Thu, Nov 21, 2013 at 12:57:49AM -0500, Fulko Hew <<a href="mailto:fulko.hew@gmail.com">fulko.hew@gmail.com</a>> wrote:<br>
> a) it operates backwards to what I was trying to do.<br>
> ie. it allows RPCing into child threads, to ask them to be workers.<br>
> but what I wanted were workers that allowed RPCing the parent<br>
> to retrieve info regarding what the workers need to do,<br>
<br>
</div>You can still send events from the worker to the parent to request<br>
information (via AnyEvent::Fork::RPC::event), so you wouldn't really need<br>
to redesign, you'd just have to think of ::event as a request, and the<br>
request sent (in response, by the parent) as delivering the request info.<br><div class="im"></div></blockquote><div><br><div class="gmail_default" style="font-family:courier new,monospace;display:inline">Sorry, my mistake. I had incorrectly stopped reading </div>
<div class="gmail_default" style="font-family:courier new,monospace;display:inline">when I saw<br>the statement about 'no return values'. But I now understand how<br>I could use that to implement my scenario.<br>
</div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">
> b) I get further with respect to multi-threaded operation, but it looks like<br>
> the RPC/children of an AnyEvent::Fork application must be non-blocking,<br>
> as in the<br>
<div class="gmail_default" style="font-family:courier new,monospace;display:inline"></div><br>
</div>The fact that the default backend actually is blocking is a big hint that<br>
blocking is fine, don't you think so? :)<br></blockquote><div><br><div class="gmail_default" style="font-family:courier new,monospace;display:inline">Sorry again, but I get confused with which is frontend versus backend.<br>
</div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">(_I_ think front end is the parent and backend is the child/children<br>where </div> <div class="gmail_default" style="font-family:courier new,monospace;display:inline">
RPC execution takes place.)<br><br></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">I was hoping that a block in the backend wouldn't block 'other' backends.<br></div>
<div class="gmail_default" style="font-family:courier new,monospace;display:inline"><br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">> Example 3: Asynchronous backend with Coro<br>
><br>
> Unfortunately, my children do (must) block, and that breaks this<br>
> approach.<br>
<br>
</div>Why do you (wrongly) think that blocking breaks anything? What do you<br>
think breaks when you block?<br><div class="im"></div></blockquote><div><br><div class="gmail_default" style="font-family:courier new,monospace;display:inline"></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">
I was expecting, that since the RPC is being executed in a 'forked'<br></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">environment, that a block in the RPC would not block the parent<br>
from issuing another RPC (to effectively another, separate? forked<br>environment).<br><br></div><span style="font-family:courier new,monospace">[I attached my test code. If you enable Coro sleep, it works, but<br><div class="gmail_default" style="font-family:courier new,monospace;display:inline">
if you enable the blocking sleep, each RPC invocation blocks everything.]<br></div></span><br><div class="gmail_default" style="font-family:courier new,monospace">... I also tried creating two AnyEvent::Fork->new()<br>
</div><div class="gmail_default" style="font-family:courier new,monospace">that I hoped would duplicate the child in which to execute<br>the RPC (similar to your Coro::async_pool), but that created<br></div><div class="gmail_default" style="font-family:courier new,monospace">
even more errors.<br></div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">
> That's why I wanted 'real' forked children.<br>
<br>
</div>I feel you are overly negative towards working approaches :)<br></blockquote><div><br><div class="gmail_default" style="font-family:courier new,monospace;display:inline">I'm trying not to be. :-(<br>It may seem that way, only because<br>
</div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">I haven't yet been able to achieve what I need.<br></div> </div></div><br></div></div>