Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
4.2-beta1
-
None
Description
I leave postponed responses for a separate thread to handle. When Cancellable#cancel() is invoked I signal this background thread and wait for it to signal back before returning true or false from cancel() depending on whether the response was cancelled or already sent. I'm assuming it is not OK to always return true immediately and attempt in the background to signal another thread to tell it to not submit a response, which it may still do if it doesn't get the signal in time.
My program deadlocks if the background thread tries to submit a response after Cancellable#cancel() has been invoked. The IOReactor worker thread (inside cancel()) waits on the background thread, and the background thread is trying to submit a response, apparently needing a lock held by the IOReactor worker thread.
Not sure if this is a bug or if I am "doing it wrong". But I think this is a trap many will fall in, so it would be best if this problem could be avoided.