From: Michael Malone <michael.malone@...>
Date: 2009-03-18T05:09:18+09:00
Subject: Re: does IO.read block?


>
>>  I borrowed it from a process detach method elsewhere, so it might 
>> not be exactly what I want.  However, it had no effect.  The problem 
>> still exists.
>
> I do not know whether you plan to exec your forked process but if so 
> you can make your life much easier by using Open3.  Then you can do
>
> # from memory
> require 'open3'
> Open3.popen "cmd args" do |in,out,err|
>   out.puts "foo"
> end
>
I'm not running a command as such, I'm running a block of code.  Also, I 
have come to the conclusion that I actually don't care about the output 
in the child process.  Is there an easy way to redirect to /dev/null?
>
>> An interesting effect I noticed, is if I remove my call to 
>> Process.wait(pid) then it displays almost identical behaviour!  It 
>> runs perfectly some times, and occasionally just hangs.  However, if 
>> I'm not collecting child processes, then I would expect to hit my 
>> ulimit at the same place every time and for the fork() call to fail 
>> noisily.  The docs don't mention anything on this.  Is it possible 
>> that my child processes aren't being collected correctly, thus the 
>> rlimit is being hit, but Ruby *believes* the process is collected, so 
>> its internal rlimit is not reached, so it calls fork() regardless?
>
> Could just mean that you create new processes faster than old ones are 
> closed.
This is almost certainly true.  I didn't think of that.  And I finally 
worked out how to use ulimit, realising the processes are per user and 
in the realm of 26000.  You're right, it probably isn't that.
>
> I'd rather ask: what is the problem you are trying to solve?  I still 
> lack the big picture - we're talking about details here all the time 
> but it's difficult to stay on track when the context is missing.

Sorry, I was trying to ask specific questions rather than asking the 
good folks on ruby-talk to debug my script for me entirely.  I am 
writing a thread pool, which accepts jobs as block parameters and by 
calling run_process(&block) the job is run in an entirely new process, 
with the thread from the pool calling fork(), creating a pipe to 
transfer any exception objects back to the parent (hence the 4th pipe) 
and then waiting to collect the child thread's status.  The main use of 
this is for compiling concurrently with the thread pool, then linking 
concurrently with the process option.

Michael



=======================================================================
This email, including any attachments, is only for the intended
addressee.  It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
 altered or corrupted during transmission.
=======================================================================