I've constructed  a simple example just using the zkpython library with
condition variables, that will deadlock. I've filed a new ticket for it,

https://issues.apache.org/jira/browse/ZOOKEEPER-763

the gdb stack traces look suspiciously like the ones in 591, but sans the
watchers.
https://issues.apache.org/jira/browse/ZOOKEEPER-591

the attached example on the ticket will deadlock in zk 3.3.0 (which has the
fix for 591) and trunk.

-kapil

On Mon, May 3, 2010 at 9:48 PM, Kapil Thangavelu <kapil.f...@gmail.com>wrote:

> Hi Folks,
>
> I'm constructing an async api on top of the zookeeper python bindings for
> twisted. The intent was to make a thin wrapper that would wrap the existing
> async api with one that allows for integration with the twisted python event
> loop (http://www.twistedmatrix.com) primarily using the async apis.
>
> One issue i'm running into while developing a unit tests, deadlocks occur
> if we attempt to close a handle while there are any outstanding async
> requests (aget, acreate, etc). Normally on close both the io thread
> terminates and the completion thread are terminated and joined, however
> w\ith outstanding async requests, the completion thread won't be in a
> joinable state, and we effectively hang when the main thread does the join.
>
> I'm curious if this would be considered bug, afaics ideal behavior would be
> on close of a handle, to effectively clear out any remaining callbacks and
> let the completion thread terminate.
>
> i've tried adding some bookkeeping to the api to guard against closing
> while there is an outstanding completion request, but its an imperfect
> solution do to the nature of the event loop integration. The problem is that
> the python callback invoked by the completion thread in turn schedules a
> function for the main thread. In twisted the api for this is implemented by
> appending the function to a list attribute on the reactor and then writing a
> byte to a pipe to wakeup the main thread. If a thread switch to the main
> thread occurs before the completion thread callback returns, the scheduled
> function runs and the rest of the application keeps processing, of which the
> last step for the unit tests is to close the connection, which results in a
> deadlock.
>
> i've included some of the client log and gdb stack traces from a deadlock'd
> client process.
>
> thanks,
>
> Kapil
>
>
>
>

Reply via email to