Re: [Visualpython-users] gdisplay objects seldom work

[Jonathan B. <jbr...@ea...>]

On Tue, 2003-09-30 at 08:49, Roger Fearick wrote:
> On Mon, 29 Sep 2003, Bruce Sherwood wrote:

> The result is a frozen window, usually displaying the minimum
> axes possible (i.e. the problem seems to lie in the creation of the
> window). 
> In general, related activity in a display window will continue.

Can you send me an example of this behavior?  All of the locks that I
have seen have locked all of the windows.  Sometimes there would be a
hiccup and the main window would jump, but the main window would never
keep rendering new frames when the other windows were frozen.

> I guess that this is related to threading and some deadlock. 

I think that the problem was that the Python thread and the rendering
thread were obtaining a pair of mutex locks in opposite order from each
other, creating a race condition to lock the second mutex and the
subsequent deadlock.

> I've
> tried to trace through the code and find whereabouts the stall
> is happening, but with little success - the usual problem with an
> intermittent fault! However, some tests did seem to suggest that it got
> lost between the exit from gdisplay's __init__ and the next call to the 
> class instance.
> One thing is that it does seem worse on machines that are a little tight 
> on memory.
> It is the one thing that does upset students a little with the visual 
> package, otherwise they seem to like it.
> 
> Roger.

I have a VPython script that consistently locked up my computers, and
now it runs fine with the Boostified version of VPython.  However, just
because I can't reproduce the bug anymore in this case doesn't mean it
isn't there.  I could use a few more people's eyes on this one.

I haven't written generic build scripts for any platform, but I can
e-mail a Windows binary to anyone that wants to help test this problem. 
The attachment would be a .5MB tar.gz file.  I can also work with anyone
who wants to build it on their Linux or Mac to help test this fix.

Thanks,
Jonathan Brandmeyer