On Thu, Sep 6, 2012 at 5:10 PM, Ted Ross <tr...@redhat.com> wrote: > 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. > > 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? >
Regarding option (1), I think it would definitely be architecturally undesirable since it assumes we are welded to a single driver rather than leaving people the option to write their own. Regarding option (2) I'm assuming you mean pn_connection_t since pn_connector_t already has a void* context field. I think it makes sense to have void* context on pretty much all the significant objects. I will very shortly have reason to want one on pn_message_t to make messenger offer explicit acking, and I've already encountered a bunch of cases where it would be nice to have them on pn_link_t, pn_session_t, and/or pn_connection_t. I suspect option (2) is just more generally useful since you could use it not only to implement backpointers to pn_connector_t, but also to any arbitrary application state you might care to associated with a connection. Why don't we try option (2) and see how it works out for you? --Rafael
