I would suggest that you not stop the subscriber messenger in the main thread. Rather, stop it in the subscriber thread right before it exits. Alternatively (preferably), you should pthread_join the thread in main before stopping the messengers.

It looks to me that you've got a race condition where main is stopping mSub at the same time the thread is processing messages on mSub.

Keep in mind that pn_messenger_send is only going to block until the message has been pushed to the socket. It will not wait for the message to be received and processed by the other thread.


On 06/14/2013 07:10 AM, Frank Quinn wrote:
Hi Folks,

See attached code: I'm encountering a deadlock when I try to stop messengers. The general workflow is:

1. Create pub and sub Messengers
2. Start the Messengers
3. Thread sub off onto its own thread as recv is a blocking call
4. Publish round trip from the pub messenger to the sub messenger with a destroy subject (recv is uninteruptable at the moment so this is our only to interrupt it)
5. Stop the messengers

When I try and stop the messengers, the application deadlocks with the following backtrace (there is only one thread running at this point as the subscribe thread has since exited):

Thread 1 (Thread 0x7f38181a4840 (LWP 6688)):
#0  0x0000003518ce99ad in poll () at ../sysdeps/unix/syscall-template.S:81
#1 0x000000309c226a1c in poll (__timeout=<optimized out>, __nfds=<optimized out>, __fds=<optimized out>)
    at /usr/include/bits/poll2.h:46
#2 pn_driver_wait_2 (d=d@entry=0x1a81140, timeout=<optimized out>, timeout@entry=-1)
    at /usr/src/debug/qpid-proton-0.4/proton-c/src/posix/driver.c:752
#3 0x000000309c226c42 in pn_driver_wait (d=0x1a81140, timeout=timeout@entry=-1)
    at /usr/src/debug/qpid-proton-0.4/proton-c/src/posix/driver.c:807
#4  0x000000309c2242d3 in pn_messenger_tsync (messenger=0x1a81050,
predicate=0x309c222d80 <pn_messenger_stopped>, timeout=<optimized out>)
    at /usr/src/debug/qpid-proton-0.4/proton-c/src/messenger.c:623
#5  0x0000000000400ffb in main () at qpid_deadlock_repro.c:123

Is this the correct workflow for this or am I missing a flush or unlock step somewhere along the way?



Please consider the environment before printing this e-mail.

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient or have received this e-mail in error, please advise the sender immediately by reply e-mail and delete this message and any attachments without retaining a copy.

Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

*Please consider the environment before printing this email.*

*Visit our website at http://www.nyse.com
***************************************************************************** Note: The information contained in this message and any attachment to it is privileged, confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by replying to the message, and please delete it from your system. Thank you. NYSE Euronext. *

Reply via email to