[
https://issues.apache.org/jira/browse/PROTON-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13458230#comment-13458230
]
Ted Ross commented on PROTON-30:
--------------------------------
I'm committing a temporary solution to the problem: pn_driver_wait calls
pn_driver_wait_[123] in sequence. A multi-threaded application can call the
sub-functions directly.
This change is *not* reflected in the driver API due to its temporary-hack
nature. A user of this "feature" will need to provide his or her own function
prototypes.
> The driver cannot be cleanly used in a multi-threaded application due to
> pn_driver_wait
> ---------------------------------------------------------------------------------------
>
> Key: PROTON-30
> URL: https://issues.apache.org/jira/browse/PROTON-30
> Project: Qpid Proton
> Issue Type: Wish
> Components: proton-c
> Reporter: Ted Ross
>
> An efficient multi-threaded application based on proton-c will want to have
> one thread blocked on pn_driver_wait if there's no other work for it to do.
> Unfortunately, pn_driver_wait does thread-unsafe things with internal driver
> data structures before and after it blocks on the FD set.
> The alternatives are to quiesce all threads prior to calling pn_driver_wait
> (which is undesirable for performance reasons) or to divide pn_driver_wait
> into three sections, the first and third of which can be invoked with a lock
> held and the second of which (the poll call) can be invoked without a lock.
> Alternatively, a driver API better suited to multi-threading could be
> developed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
