[M3devel] Fork bug

[Tony Hosking]

Or, more directly, why do we not simply use vfork for Process.Create as we used to?  It suspends the parent until the exec, which avoids all the nastiness, so long as we are careful in the child until the exec.

As I recall though, cvsup relied on full-blown fork, which was how we ended up in this mess in the first place.

So, that means a fix is still needed.

I suspect we will need to revise the implementation of MUTEX to avoid having the pthread mutex held while the Modula-3 MUTEX is held.  Instead, we’d need state in MUTEX to record the holder, plus a waiters field to record those waiting for the mutex.  Then, we can guarantee that no pthread mutex will be locked at the time of the fork using the machinery we already have.

On Jul 3, 2014, at 3:28 PM, Tony Hosking <hosking at cs.purdue.edu> wrote:

> I wonder if we should not move to a surrogate parent model to make this cleaner in general?
> Since fork is (or should be) only used in service of creating a new process (i.e., fork + exec) then this technique would save us a lot of grief.
> Thoughts?
> 
> In the surrogate parent model, a program forks a child process at initialization time. The sole purpose of the child is to serve as a sort of "surrogate parent" for the original process should it ever need to fork another child. After initialization, the original parent can proceed to create its additional threads. When it wants to exec an image, it communicates this to its child (which has remained single-threaded). The child then performs the fork and exec on behalf of the original process. 
> 
> 
> Begin forwarded message:
> 
>> From: Peter McKinna <peter.mckinna at gmail.com>
>> Subject: Fork bug
>> Date: July 2, 2014 at 10:30:24 PM EDT
>> To: Antony Hosking <hosking at cs.purdue.edu>
>> 
>> Hi Tony,
>> 
>>   That fork bug on posix doesn't appear to be fixed, so just to recap the problem. In the threadtest program if you have a bunch of threads creating mutexes and having them collected then get a thread that does a few forks what can happen is that the child executes  atforkchild  as I think the first thing it does which calls initwithstackbase which does an allocation and possible collection. Unfortunately the weaktable from the parent may be non empty and this is the only thread executing. It calls the cleanup of those mutexes of nonexistant threads some of which may be locked. If they are locked then pthread_mutex_destroy returns ebusy. Then the child exits with the abort in pthread_mutex_delete.
>>   Whether the abort is needed I dont know. In this case the error can be safely ignored. One could try to see if the owner of the mutex is still alive and not abort in that case. Otherwise if one is sure the child is going to do an exec almost immediately then disabling the collector in atforkchild could work.
>>   In the broader picture anything thats got a weak ref still active could cause problems if one thread does a fork. The weak callback could do anything.
>>   Anyway I dont know what the fix is.
>> 
>> Peter
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140703/205bf9e2/attachment-0002.html>