On 03/11/2013 11:42 AM, Michael Goulish wrote:

Please Note -

I thought that a document like this would be worthwhile
at least to stimulate discussion, and to make sure that
we all have a common understanding of this issue.

I personally had a limited understanding of this topic,
before having conversations, which I may not have fully
understood or accurately rendered.

I will alter this doc to make it more accurate & complete based
on discussion on this list.  Since this doc seems likely to
change greatly & rapidly as a result of discussion, I have not
checked it in to the source tree yet.





Proton Messenger Threading Considerations
==================================================

_as of version 0.4_

Proton Messenger is unthreaded, and thus can easily be
integrated into any pthread-based threading model that
the application developer chooses.

However some of the I/O calls that can be made with
Messenger will block, waiting for messages to arrive or
be sent.  In 'greenthread' environments that emulate
multithreading within a single OS-native thread, blocking
calls will block the entire application.

A possible future direction for Proton would allow the
application to substitute its own driver, and would make
the Messenger library driver-agnostic.  This would allow
the implementation of greenthread-friendly Messenger-based
applications.


N that proton is not special in regard to green threads, any library with blocking calls would be the same. The important thing is to document which calls can block and when, which you're doing in another thread.

I'd add a word on thread safety: Messenger instances are not thread safe, so the application must takes steps (mutex locks etc.) to ensure no concurrent function calls _with the same pn_messenger_t pointer parameter_. However calls on _different_ messenger instances _are_ thread safe, so a multithreaded application can use multiple messangers concurrently

Effecively what this is saying is that the messenger library doesn't have any global variables used in calls that take a pn_messenger_t (it doesn't does it?)

Cheers,
Alan.

Reply via email to