Win VM modifications

[Andreas Raab]

> 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.

The first question coming to my mind is: Does wx use any kind of 
exception handling? IIRC, then wx is C++ right?! If so, exception 
handling might play a significantly different role here.

> 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.

That's what I would expect.

> In the VM, a callback is initiated with:
> 
>    interpreterProxy->signalSemaphoreWithIndex(semaIndex);
>    if (setjmp(jmpbuf) == 0) {
>        interpret();
>    }

That too. Except that (with multiple callbacks) one would expect that 
jmpbuf is dynamically allocated and passed to the supporting call to "Wx 
returnFromCallback" somehow...

> 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.

If correct, this is indeed interesting (and fixable if need be). But 
what exactly qualifies as "being initiated by a primitive call"? E.g., 
in almost all situation ioProcessEvents is called when a primitive is 
called (the rare exception are true interrupt checks for long-taking 
primitives). Or do you have "special" primitives in mind?

> 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?

There is only one way to signal the semaphore and that's the above one 
(assuming you're running single-threaded; for multi-threaded execution 
signalSemaWithIndex() isn't always thread-safe and that's why win32 uses 
asyncSignalSemaWithIndex() in some places but this shouldn't be an issue 
here).

So I would say it is extremely unlikely that it's related to how/if the 
semaphore gets signaled. I think it's something with the callbacks.

Cheers,
   - Andreas