[Vm-dev] Win32 Event VM prototype

[Stephen Pair]

Andreas,

I think this recursion situation will lead to undesirable concurrency safety
issues (you are interrupting squeak processes at unpredictable and likely
unsafe points).  I'm sure you already know this.  I mentioned having two
calls, one for interpret() and another for handling events (let's call it
sendMessage()).  The latter (sendMessage()) might be implemented by having a
general call that, rather than scheduling and interpreting all active squeak
processes, just dispatches and executes one specific message uninterruptably
and returns without allowing other processes to be scheduled.  You would
somehow need to interrupt interpret() if it is actively running squeak
processes for the duration of sendMessage() and you would probably want to
disable GC during this call.  It might also work to simply make
sendMessage() wait until interpret() completes (but then I think you might
be more at the mercy of OS buffer overflow handling behavior rather than be
able to do something more intelligent in  overflow situations inside your
message enqueueing logic (i.e. giving priority to certain kinds of events
while more eagerly dropping others)).

You would call sendMessage() in response to Windows messages (it would do
nothing but safely and quickly enqueue messages for interpret()).  You could
have a third call, waitUntilRunnable() and then you would have a loop in an
OS level thread that repeatedly calls waitUntilRunnable() followed by
interpret().  The Windows messages would be calling sendMessage() to unblock
waitUntilRunnable() and queue up work for interpret().

- Stephen

On Sat, Nov 14, 2009 at 1:02 AM, Andreas Raab <andreas.raab at gmx.de> wrote:

>
> Folks -
>
> I just finished a prototype of the Win32 event VM to illustrate some of the
> practical impact. It makes a really nice demo:
>
> 1) Download the VM from
>
>   http://squeakvm.org/win32/experimental/Squeak-3.11-EventVM.zip
>
> 2) Fire up an image with this VM (I used a trunk image) and execute
>
>   AbstractSound stereoBachFugue play.
>
> 3) Observe the sound behavior you get when you:
>   * drag the window around
>   * go to the system menu
>   * click the window close button
> In all of the above situations the sound play will be interrupted,
> replaying the current buffer over and over.
>
> 4) Execute the following:
>
>   (ProcessorScheduler classPool at: #BackgroundProcess) terminate.
>
> You should see a printf that tells you "entering windows main loop" which
> indicates that you're now running under the new regime.
>
> 5) Observe the sound behavior you get when you:
>   * drag the window around
>   * go to the system menu
>   * click the window close button
> In all of these situations the sound will now keep playing. There can be a
> temporary hickup due to lack of buffering but other than that everything
> continues smoothly.
>
> For those interested I'm attaching the relevant changes (only for playing
> around; these changes are NOT ready to be integrated). The Windows main loop
> has been changed to read like here:
>
>  /* prepare active process and do first time interpret() for old images */
>  prepareActiveProcess();
>  /* do not allow recursive interpret() */
>  allowInterpret = 0;
>  /* interpret() will be left after nuking background process */
>  interpret();
>
>  /* now do a classic Windows main loop */
>  printf("Entering Windows Main Loop\n");
>  SetTimer(stWindow, 1, 50, NULL); /* make sure we interpret() every 50ms */
>  allowInterpret = 1; /* okay to interpret() now */
>  while (GetMessage(&msg, NULL, 0, 0) > 0) {
>        TranslateMessage(&msg);
>        DispatchMessage(&msg);
>  }
>
> and then you call interpret() whenever you feel like it. I'm doing that
> from MainWndProc in response to Windows messages:
>
>  /* A bit of extra paranoia: I'm not sure if calling interpret()
>     through checkForInterrupt() recursion into ioProcessEvents()
>     is safe (probably not). */
>  if(!inProcessEvents && allowInterpret) interpret();
>
> Of course, this isn't finished yet by any means. There are some odd effects
> when a recursion does happen, and somewhere I'm loosing events. But I think
> it does illustrate the point that I'm trying to make.
>
> BTW, does anyone know if wxSqueak is still active? I think the behavior of
> this VM would be a perfect fit for their needs.
>
> Cheers,
>  - Andreas
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20091114/4bd8956e/attachment.htm