Hi Eliot,

The child process needed to establish signal handlers for the timer signals, which IIRC did not get passed to the child process on a fork() call. The solution was to turn off these signals before the fork, and turn them back on afterwards (in both parent and child). There are some comments in the UnixOSProcessPlugin>>forkSqueak: method that give some further explanation.

I have not yet had a chance to look into this with Cog but I suspect that the use of pthreads for timer events may be a problem for #forkSqueak:. I don't think that pthreads are reestablished in a child process after a fork(), so I am guessing that the missing piece would be a way for the child Squeak process to restart the timer threads. If that's the issue, it would probably be easy to resolve if we provide a restartTimerThreads() function, which could be a no-op for the traditional VM. I cannot explain why the parent process crashes when calling #forkSqueak: from Cog, possibly there is some interaction between the signal handling and pthreads (signal delivery to pthreads on Linux is a bit awkward).

I have not yet had a chance to look into this so treat the above as pure speculation.

If we don't have a solution to this, I don't think it's unreasonable to just fail the #forkSqueak primitives when running on a VM that does not support them. I could put a check for this based on image format version in the plugin as a workaround to prevent VM crashes. For most people, the only practical impact would be that many of the OSProcess unit tests would not run.

Dave

On Mon, Sep 20, 2010 at 02:49:35PM -0700, Eliot Miranda wrote:

Hi David,

what's the reason for shutting down interval timers around fork?  What

was the issue that necessitated this in the first place? We're likely getting bit by this and I want to try and keep the solution as simple as possible.

best Eliot

On Sat, Sep 4, 2010 at 7:20 AM, David T. Lewis lewis@mail.msen.com wrote:

...

I think that you have confirmed that #forkSqueak does not work on a Cog VM. The likely reason for this is that #forkSqueak involves temporarily disabling timer signals from the operating system, then reenabling them in both the child and parent after the fork(). The Cog VM is using a different underlying timer mechanism (pthreads etc) so the current #forkSqueak mechanism would probably need to be redone for Cog. I have not looked in to this at all, but I did expect that this might be a problem and I think you have confirmed it in the log below.

Dave

On Fri, Sep 03, 2010 at 09:52:29AM -0300, Casimiro de Almeida Barreto wrote:

...

Here's the log:

Untrustedir /home/casimiro/Desenvolvimento/cog.work/secure UnixOSPrReceiversessionIdentvaria DependentsArray(a UnixProcess with pid 3490) fier: #[202 58grimReaper: siona Process in [] in [] in UnixOSProcessAccessor>> grimReaperProcessigChldSemaphore: a Semaphore(a Process in [] in [] in Uni UnixOSPrReceiversessionIdentifier: epend#[202 58 13 UnixProcess with pid 3490) 6] grimReaper: sio a Process in [] in [] in

UnixOSProcessAccessor>>

...

grimReaperProcessigChldSemaphore: a Semaphore(a Process in [] in [] in Uni UnixOSPrReceivercanObtainSessionIdenpend#[202 58 13 86]xProcess with pid 3490) ifierFromPlugin:grimReaper: a Process in [] in [] in UnixOSProcessAccessor>> grimReaperProcessigChldSemaphore: a Semaphore(a Process in [] in [] in Uni UnixOSPrReceiversessionIdentifier: epend#[2sArray(a UnixProcess with pid 3490) 2 58 13 86] grimReaper: siona Process in [] in [] in UnixOSProcessAccessor>> grimReaperProcessigChldSemaphore: a Semaphore(a Process in [] in [] in Uni UnixProcess>>redirect:to:- - - - - - - - - - - - - - - - - - - - - [] in PipeableOSProcess class>>forkSqueakAndDoThenQuit:errorPipelineStream:headl

Compiler>>evaluate:in:to:notifyiningTo:toPrecision:maxEpochs:reportingEach:ss:

...

PluggableTextMorphPlus(PluggableTextMorph)>>handleEdit: MorphicEventh(Morph)>>handleEvent:nt:ndTo: [] in HandMhandleFocusEvent:nt:using::with:h: ...etc...>>handleEvent:nt::clear:r:ing:

BTW, XDisplayControlPlugin explodes cogvm at my face... but seems to be required by TranscriptStream (trying to figure out what's going on there... then I'll report the problem properly).