RE: Hanging renders

I do the locks in the tools because it's their databases I'm reaching in and
changing. :) 

I've put in more debugging code. Something's failing and not throwing an
exception, and causing a _release to be missed. That's fine within the
thread that did it, but stops other threads from doing any work. I might
have to go to the level of maintaining a stack of _acquirers and making sure
that any _release is called by the same method as the most recent _acquire. 

-----Original Message-----
From: pyds-dev-admin-iYtK5bfT9M//Ad8WF/[email protected]
[mailto:pyds-dev-admin-iYtK5bfT9M//Ad8WF/[email protected]] On Behalf Of Georg Bauer
Sent: Wednesday, 14 July 2004 7:42 AM
To: Garth T Kidd
Cc: 'PyDS Developer List (E-Mail)'
Subject: Re: [Pyds-dev] Hanging renders

Hi!

> mesh(_acquire): waiting for lock at Tue Jul 13 16:49:24 2004

Yep, that's a hanging lock.

> I *suspect* I've either got a single thread trying to acquire the lock 
> twice, or two threads deadlocking, or one thread dying whilst it has 
> the lock. Is there any infrastructure to help me resolve this?

Ugh. There was some, but I don't think it's still fully in place. But since
you do know that it's in the mes _acquire call, you can just overload
_acquire in MeshTool and put in some debugging code and wait for the next
time the problem occurs. Since locks are related to tools, the blocking
usually comes from just missing _release() calls.

My favorite would be the index_html: you do a self._acquire outside a
try:finally: block - usually I do try:finally: blocks to acquire and
release, so that exceptions don't leave locks dangling. Another thing might
be related to your ObjectDetail class, where you rely on the tools locks -
this would do locks in foreign tools, so there might be chances for
deadlocks.

bye, Georg


_______________________________________________
Pyds-dev mailing list
Pyds-dev-iYtK5bfT9M//Ad8WF/[email protected]
http://www.westfalen.de/cgi-bin/mailman/listinfo/pyds-dev