Interesting, I did try this with some debug messages. Although I was using
+toolbar,+menus,+tab,+win at the time. And also have run in managed mode
with the debug messages. I did worry that the patch may cause the program to
deadlock but saw no sign of it from my testing.
The specific problem the patch address is that during window destruction it
is possible for a ConfigureNotify event to come in. If that messages is
timed right then the HWND pointer points to a valid window when ProcessEvent
is called. Then the thread destroying the window proceeds in deleting the
WND structure for the HWND. In the event processing loop, ConfigureNotify is
called and then EVENT_QueryZOrder.
In QueryZOrder we get the WND pointer for the HWND but because the HWND is
now invalid we receive NULL. When we try to do X11DRV_WND_GetXWindow with
that we get null and then X dumps out with an error message.
Placing the event processing inside the critical section seemed like a
logical fix., but maybe another one needs to be found.
-aric
gerard patel wrote:
> At 09:50 AM 5/9/00 -0500, you wrote:
> >This patch places the X event processing into the critical section that
> >locks the WND pointer. This prevents a race condition that occasionally
> >occurs on window destruction.
> <snip>
>
> Did you test this patch when running with -debugmsg? I have a program
> that is working fine with your patch (or without), but when I use
>
> -debugmsg +relay,+win,+dosfs,+file
>
> *with* the patch, it hangs when displaying a messagebox (managed)
> with 'holding lock of level 2' and an infinite loop of exceptions.
>
> Bye
> Gerard
