[ 
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

Reply via email to