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 

> 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