[Vm-dev] Win32 Event VM prototype

Igor Stasenko siguctua at gmail.com
Sat Nov 14 15:08:25 UTC 2009


2009/11/14 Stephen Pair <stephen at pairhome.net>:
>
> 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().

i'm not sure i get everything.. but given the complexity and
constraints (non-interruptable, no GC).. is a bit high.
I think better would be to make sure there is no recursive call to
interpret(), rather than deal with consequences.
I'm already proposed that.

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



-- 
Best regards,
Igor Stasenko AKA sig.


More information about the Vm-dev mailing list