Win VM modifications

[Rob Gayvert]

> Well, there are two possibilites as far as I can tell at this point: 
> Either, there is something in the wx mainLoop() which really wants to 
> be run and isn't invoked by any of the current variants. We should be 
> able to test this by calling interpret() from *within* the wx main 
> loop. Try changing the main Squeak window proc (in sqWin32Window.c) to 
> call interpret() ... uh say ... on WM_CREATE or so. Then, call the wx 
> mainloop instead of interpret() from the VM and see if that works. If 
> the problem is really in the "outer" mainloop this should probably work.
>
> Or, and that's what I'm fearing right now, wx has a problem with 
> reentrant windows messages. The only way to know for sure is probably 
> to look around if anyone else has seen such a problem (and mind you it 
> could just be an issue with one specific message - that's all it takes 
> for a recursive crash). One thing that would indeed be useful is to 
> find out after which recursive message the system crashes (if it were 
> a specific one or two we might be able to handle these on the plugin 
> level).


I just tried out a test that demonstrates that the real culprit is the 
callback mechanism. I stripped out all of the wx initialization, event 
processes, and wx event processing from my image and vm, so it should be 
possible to reproduce this with a stock image. Here's the setup.

In Squeak, a callback process is started as follows:

    semaphore := Semaphore new.
    Wx setCallbackSemaphore: (Smalltalk registerExternalObject: 
semaphore).  "sets semaIndex"
    [ [ true ] whileTrue: [
        semaphore wait.
        Transcript show: 'processing callback'; cr.
        Wx returnFromCallback.   "longjmp(jmpbuf)"
    ]] fork.

In the VM, a callback is initiated with:

    interpreterProxy->signalSemaphoreWithIndex(semaIndex);
    if (setjmp(jmpbuf) == 0) {
        interpret();
    }

The results:

1. If the callback is initiated from Squeak by a primitive call, it can 
be called any number of times without a problem.

2. If the callback is initiated periodically (say once per second) from 
ioProcessEvents, it dies very predictably after 15 iterations.

So either (a) I'm doing something wrong with this semaphore; or (b) this 
semaphore can't be safely signaled from within the 
checkForInterrupts/ioProcessEvents context.  Or maybe it needs to be 
signaled differently in this situation?