[ruby-talk:7107] Re: fork - or threading problems

Kevin Smith <[e-mail]> wrote:
>
> >That's the topic recently discussed on ruby-list and ruby-dev ---
> >MLs in Japanese.  Currently all threads are duplicated on fork, and it
> >sometimes causes a problem.  However kill all threads but which issued
> >fork may break some library or applications.
> >
> >There is a somewhat reasonable proposal posted by matz.
> >
> >  1. Add an argument indicates whether the thread will be killed or
> >     not to Thread.new.
> >  2. That argument indicates `kill the thread' in default.
> >
> >  # eg. something like Thread.new(kill_on_fork = true).
> >
> >And comments, request, claim, or something else are wanted.

Has he suggested that this be inherited?  If a thread is
registered to be killed on fork, what happens to threads
it spawns?  What happens to things (like open sockets and
handles) which threads have open?

> >Your proposal may be included in future Ruby standard :-)
>
>Not knowing much about threads or forks, I would humbly suggest
>the possibility of turning it around. It seems to me that at the point that 
>I fork is when I would know whether I want to bring my threads along or 
>not. I might be forking some totally detached task.

Based on what I have seen elsewhere, this is very often
true.  People often fork/exec, in which case they won't care
about other threads for long.  Alternately people fork to
get a dedicated task thread.  I suspect these will usually
not work too well.

>So my suggestion would be that fork would take a parameter
>indicating whether to bring all threads along, or none. Seems simple.

I suggest that there isn't a good way to combine Ruby's
threading model with Unix forks.  They just don't mix very
well.  Well some problems have no good solutions, and the
correct solution is education, not trying to let people do
what they probably shouldn't.

In that spirit, I suggest creating a trappable exception for
attempting to fork while multiple threads are open without
saying that you really wanted to do that.  If they fork
anyways, you at least know they were warned.  Then for the
benefit of threading offer an optional argument to Thread.new
for a new thread which should actually be launched in a new
process.

Where this is really going is saying that forking and
launching threads are at different ends of the same spectrum.
It is currently not very portable, but Linux' clone() call
may give some ideas/inspiration.

Cheers,
Ben
_____________________________________________________________________________________
Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com