messenger threading considerations

[Michael Goulish <mg...@redhat.com>]

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.

Re: messenger threading considerations

[Alan Conway <ac...@redhat.com>]

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.