----- Original Message ----- > In order to make sure that it can be done, I'm attempting to use > Proton-c in a multi-threaded server environment.The basic assumptions > that I'm making are: > > 1. The root data structure that threads can operate on is > pn_connector_t/pn_connection_t. An application thread cannotuse > pn_driver_t without taking measures to ensure that it is the only > one doing so at a time. > 2. As long as no two threads are concurrently operating on the same > instance of pn_connection_t, everything should work properly. > > So far, so good. There is one interesting exception to the above. > > It will commonly be the case that a thread processing the reception > of a > message from an inbound link will need to indicate to a different > outbound link that there is now data to be sent (i.e. activate that > link > for write). It is likely that the outbound link will be associated > with > a different connection that the thread is not allowed to use because > another thread may be processing it concurrently.
FYI, I had to deal with this with the OpenMAMA integration work. The publisher example program also has a reply queue and so subscribes for incoming messages. To be safe I had to use two pn_messenger_t instances, one for the outbound and one for the inbound. It was a bit ugly but because I am listening for replies on another thread while publishing on the main thread I wasn't sure what else I could do until Proton handled multiple threads. > > This is not difficult to handle, but it requires that my threading > layer > be able to get the pn_connector_t associated with the link. Proton-c > provides the following linkage: pn_link_t => pn_session_t => > pn_connection_t. There's no way to get the pn_connector_t though. > > So, I think I need one of two possible changes: > > 1. Provide linkage from pn_connection_t to pn_connector_t (may be > architecturally undesirable), or > 2. Add a void* context field to pn_connector_t. > > Thoughts, Feelings, Emotions? Whichever way you go I'm presuming that much of this will get hidden underneath the pn_messenger_t interface.(?) William > > -Ted > >
