----- Original Message ----- > On 09/06/2012 05:44 PM, William Henry wrote: > > > > ----- 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.(?) > > To be clear, I'm looking at the underpinnings of messaging > intermediaries (brokers, routers, proxies, firewalls, toolkits, etc.) > rather than endpoints. I don't think that pn_messenger_t is relevant > in > such environments. However, there's no reason why a multi-threaded > client or server couldn't use the same patterns. There won't be any > benefit unless the endpoint is dealing with multiple connections > though. >
Ack. William > > > > William > > > >> -Ted > >> > >> > >
