[omniORB-dev] Re: [omniORB] omniORBpy deadlock / termination problem.

[Harri Pasanen]

On Friday 03 October 2003 17:23, you wrote:
> On Monday 22 September, Harri Pasanen wrote:
> > I don't have time to dig in further at this time.  Following
> > backtrace shows what the threads are doing at the moment of the
> > deadlock, which seems to be over the python's GIL, threads 7 & 1,
> > pyThreadCache.cc
>
> Thread 7 is trying to acquire the GIL. Thread 1 is waiting for
> thread 7 to exit.
>
> I suspect the problem is caused by either thread 1 or thread 3,
> both of which have come through your application code. Is one of
> them holding the GIL?  If so, that would explain the deadlock.

Attached is our latest patch to omniORBpy to remedy the situation.  A 
collegue, (Teemu) took up from where I had arrived to and analyzed 
what was happening and came up with this patch.

Changes introduced:

1. A shutdown method that is registered with Python's atexit module.  
This is required to properly close pyThreadCache, which needs to run 
Python code, so python still needs to be present.   Otherwise it can 
be that  when pyThreadCache is destructed at omniORB cleanup during  
process exit, the python interpreter has already gone.

2. pyThreadCache join needs to be in python's ALLOW_THREADS macros, 
otherwise pyThreadCache cannot be shut down from a python method.  
(And the previous atexit change should ensure it is always called 
from a python method).

3. pyThreadCache table mutex was split from thread kill mutex to 
optimize the thread killing, the former mutex being too long lived.

Let us know what you think of the patch.

Harri
-------------- next part --------------
A non-text attachment was scrubbed...
Name: omniorbpy-deadlock-fix.diff
Type: text/x-diff
Size: 3918 bytes
Desc: not available
Url : http://www.omniorb-support.com/pipermail/omniorb-dev/attachments/20031013/07418c2d/omniorbpy-deadlock-fix.bin