<br><br><div class="gmail_quote">On Wed, Dec 2, 2009 at 9:13 AM, David T. Lewis <span dir="ltr">&lt;<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>&gt;</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 Wed, Dec 02, 2009 at 05:26:53PM +0100, Nicolas Cellier wrote:<br>
&gt;<br>
&gt; Xtream is not functional yet, it is just a three evenings shot.<br>
&gt; Especially pipelines are quite tricky with a forked process... I got<br>
&gt; to rest a bit and think.<br>
<br>
</div>Are you referring to pipelines in the sense of unix command pipelines?<br>
This is indeed tricky, and requires for sure that streams on pipes<br>
be set to non-blocking mode, otherwise you lock up the VM (*). If<br>
you have the CommandShell package loaded, you may want to look at<br>
the tests in category &quot;testing-pipelines&quot; in CommandShellTestCase<br>
for examples.<br>
<br>
In CommandShell, the necessary methods are just hacked into subclasses<br>
of StandardFileStream. The basic approach is to set non-blocking<br>
mode for pipe reads, then use AIO notification to signal data<br>
available. The process that is reading data from the pipe waits on<br>
a semaphore, then reads the available data. This prevents the VM<br>
lockup problem, and allows lots of processes to concurrently read<br>
from pipe streams.<br>
<br>
I&#39;m sure the StandardFileStream hack is not what you want, but it<br>
might provide some ideas.<br>
<br>
(*) Of course if you use threads in the VM, this would be different,<br>
but that is another subject I think.<br></blockquote><div><br></div><div>Yes it is, but FYI it is fixed in the threaded VM.  So hopefully this issue will go away soon :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
Dave<br>
<br>
<br>
</blockquote></div><br>