<font style="font-family:courier new,monospace" face="courier new,monospace"><br></font><br style="font-family:courier new,monospace"><div style="font-family:courier new,monospace" class="gmail_quote">On Mon, Feb 27, 2012 at 12:25 PM, Marc Lehmann <span dir="ltr"><<a href="mailto:schmorp@schmorp.de">schmorp@schmorp.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Mon, Feb 27, 2012 at 11:01:54AM -0500, Fulko Hew <<a href="mailto:fulko.hew@gmail.com">fulko.hew@gmail.com</a>> wrote:<br>
> And this seems to be causing networking difficulties because<br>
> of either the amount of TX queuing, or RX queueing going on.<br>
<br>
</div>what kind of difficulties? at least ae::handle lets you queue as much as<br>
you want - it might not be wise to do so (because ae::handle has to buffer<br>
all the data in memory), but perfectly possible.<br><div class="im"></div></blockquote><div><br>"It appears that one or both ends fail so send some stuff or receive stuff."<br><br>My mainline (that I'm having issues with) in psuedo-code is<br>
<br>while (<>) {<br> request_thing_allocation(\&allocate_complete_cb, \%thing_data);<br>}<br><br>sub request_thing_allocation {<br> # remember_cb_and_data(@_);<br> push_write('allocate_request'); # register_thing_cb() is invoked when the response occurs<br>
...<br>}<br><br>sub allocate_complete_cb {<br> my ($allocate_response, $thing_data_ref) = @_;<br><br> my $thing = Thing->new($allocate_response);<br> $thing->populate($thing_data);<br> push_write('register_thing);<br>
}<br><br>so intuitively I'd expect the flow to go:<br>allocate_request 1 -><br> <- allocate_response 1<br>register request 1 -><br> <- register response 1<br>...<br>allocate n -><br>
<- allocate_response n<br>register n -><br> <- register response n<br><br>but instead I see on Wireshark something similar to:<br><br>allocate 1 -><br>...<br>allocate n -><br>
<- allocate response 1<br> ...<br> <- allocate response n<br>register 1 -><br>...<br>register n -><br> <- register response 1<br>
...<br>
<- register response n<br><br>Ie. No receives are processed till all requests are sent.<br><br><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">
> So my first thought was, how can I, in my part 1 loop, allow<br>
> the eventloop to detect and process transmits and receives,<br>
> and when idle, let me (my current processing loop) continue?<br>
<br>
</div>I don't understand your problem well enough - for me, it sounds more as<br>
if you want some event that tells you "now you can push more data", and<br>
indeed, AE::Handle has such an event callback, called "on_drain" - the<br>
on_drain callback is called whenever the (ae::handle) write buffer is<br>
empty, and you can write more.<br><div class="im"></div></blockquote><div><br>That was my first suspicion, but then,after adding/playing-with:<br><pre class="sh_perl sh_sourceCode"> Coro<span class="sh_symbol">::</span>AnyEvent<span class="sh_symbol">::</span>idle<span class="sh_symbol">;<br>
</span> Coro<span class="sh_symbol">::</span>AnyEvent<span class="sh_symbol">::</span>poll<span class="sh_symbol">;<br></span> Coro<span class="sh_symbol">::</span>AnyEvent<span class="sh_symbol">::</span><span class="sh_keyword">sleep</span> <span class="sh_number">0.001</span><span class="sh_symbol">;<br>
<br></span></pre>I found that I _could_ get things to 'interleave' by placing a<br>Coro<span class="sh_symbol">::</span>AnyEvent<span class="sh_symbol">::</span><span class="sh_keyword">sleep 0.001; following each of my allocate request<br>
thereby (artificially slowing things down) allowing one or both ends<br>to 'process' and thereby also allowing the response to be<br>'received and processed'. (calling idle or poll didn't affect the flow)<br>
<br> </span>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">
> My second thought was that somehow Coro can come to my<br>
> rescue, but I don't understand how I can merge the two<br>
> together, and what I need to do in my mainline and timer callback<br>
> to get it to work.<br>
<br>
</div>If your problem is that you have this kind of code:<br>
while (read more file data...)<br>
push_write<br>
<br>
and you want to "slow down" this loop to not be considerably faster then your<br>
network connection can send data, then, with coro, you can do that:<br></blockquote><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
sub wait_for_on_drain {<br>
my ($handle) = @_;<br>
<br>
$handle->on_drain (Coro::rouse_cb);<br>
Coro::rouse_wait;<br>
$handle->on_drain (undef);<br>
}<br>
<br></blockquote><div>... snip ...<br><br>This and the other example didn't affect the apparent processing flow either.<br> <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
async {<br>
while (...<br>
};<br>
<br>
Also, event processing will continue for everybody else with the above<br>
solution, which is *probably* what you want anyway.<br></blockquote><div><br>I haven't tried this yet, but...<br>In the mean time what I did do was code up something that would:<br>- queue up my requests, and then one at a time...<br>
- peel them off a list, and<br> - daisy-chain the 'register' to the end of the 'allocate response' processing, and<br> - daisy-chain the 'next allocate' onto the end of the 'register response' processing.<br>
<br>This now causes both ends to behave in that intuitive manner and<br>avoids 'whatever the problem was', with the downside of a more<br>complex/non-intuitive algorithm/processing.<br><br>I'll look and see if async { ...} alters the flow.<br>
Thanks for that suggestion.<br><br>Fulko<br><br> <br></div></div><br style="font-family:courier new,monospace">