Blocked UI after return from snapshot (MacOSX)

Hi,

IIRC, this topic was mentioned some time ago already, but I can't seem
to find the original poster's message any more. I've got the strange
behavior that occasionally, approx. for 1 out of 10 launches, the UI is
initially blocked on MacOS X. Sometimes this will go away after a
minute, or even after seconds, sometimes it blocks forever.

Starting the image with

    $VWBIN -p -= myimage.im -filein reset.st

where the file "reset.st" contains "DebuggerService
interruptAllUserProcesses", opens a process monitor showing that all
window processes are in "paused" state. I'm unsure however, whether this
is because of the forced interruption, or properly reflecting the
blocked state. After resuming the processes manually, the image is fully
functional. BTW: There's no difference between development and runtime
images.

I also discovered that an incoming external CCallback effectively
unblocks the UI, which is nice to know but not a viable solution.

All this seems to point to a race condition. I'm going to further
investigate this, but a hint as to where to look first would be very
helpful.

Anyone else experienced this? Ideas?

Andre

Andre Schnoor schrieb:
> Hi,
>
> IIRC, this topic was mentioned some time ago already, but I can't seem
> to find the original poster's message any more. I've got the strange
> behavior that occasionally, approx. for 1 out of 10 launches, the UI is
> initially blocked on MacOS X. Sometimes this will go away after a
> minute, or even after seconds, sometimes it blocks forever.

here's what I wrote to vw-dev (2007-11-04), no responses though...
----

to test apr07.1 on OSX PPC (10.4.8, iBook G4), I loaded various packages
from the VW CD, forced the Aqua Look, created a store connection
(StoreForPostgreSQL) and saved the image.

I encountered a situation where the image is unresponsive for a long
time after loading:
- start VW by double-clicking the image
- click on a finder window while the image is starting
- the image will open, presenting a deaf store connection dialog

the VW windows do not accept any mouse or keybord input then for a while
(around 30 seconds). Ctrl-(Shift-)Y did not open a (emergency) debugger
though.

after the image wakes up, the debugger finally pops up, and I can see
that the StoreDevelopmentSystem is about to be activated
(#returnFromSnapshot), and while doing this, opened the store connection
dialog.

dont know if it's related to the subsystem startup order, the OSX VM or
something else. I couldnt reproduce it neither with a minimal image
(base + Store) nor on Windows.

Holger Kleinsorgen wrote:
Ah, now I recall your post, thanks. Well, it has nothing to do with
Store so far. This also happens in an image without Store.

Andre

Andre Schnoor schrieb:
Things I noticed today, after playing with oct07.2:

- Loading WebToolkit and creating a server (doesn't need to be started)
is enough to create a image the suffers from the blocking problem.
(as mentioned above, double-click VW, choose the image, then quickly
click on a finder window before the VW windows startup)

- Starting a background process with
     [[ (Delay forSeconds: 1) wait ] repeat ] forkAt: 1
   will "heal" the image, it won't block

On Oct 13, 2007, at 6:58 PM, Holger Kleinsorgen wrote:
>
> - Starting a background process with
>     [[ (Delay forSeconds: 1) wait ] repeat ] forkAt: 1
>   will "heal" the image, it won't block
>
>


We found you'll have to assign this process to a variable, otherwise  
it will get garbage-collected.

X :=  [[ (Delay forSeconds: 1) wait ] repeat ] forkAt: 1




R
-

| >>> IIRC, this topic was mentioned some time ago already, but I can't
| >>> seem to find the original poster's message any more. I've got the
| >>> strange behavior that occasionally, approx. for 1 out of 10 launches,
| >>> the UI is initially blocked on MacOS X. Sometimes this will go away
| >>> after a minute, or even after seconds, sometimes it blocks forever.

  Same here, and has been that way at least since 7.3. I noticed that when
that happens then connecting to Seaside (this is my Seaside development image)
makes it wake up immediately.

        mjl

Holger Kleinsorgen wrote:
Weird. Whatever reliably unblocks the image should be added to

    BasicHeadfullGraphicsSystem>>setUp

I'm still experimenting here, but find it difficult to reproduce the
effect. It occurs rather randomly.

As this seems to happen on OSX only, I suspect the VM does not deliver
the first UI event properly under certain circumstances, or the event
queue gets "out of sync" in some way, i.e. it starts in the wrong state,
so the green threads do not get going as expected.

My intuition suggests we need to find that critical section in the VM
startup code. It might help to identify and fix this synchronization issue.

Andre

Not sure if this is related, but I have noticed that on some occasions
after double clicking on my Mac OS X app, it doesn't proceed with start
up until the mouse is moved.

This is with VW 7.5. It is a packaged headful image.

Once it does start, the text is mangled :(
state,
>so the green threads do not get going as expected.
>
>My intuition suggests we need to find that critical section in the VM
>startup code. It might help to identify and fix this synchronization
issue.
>
>Andre