Cliff Jansen created PROTON-889:
-----------------------------------
Summary: Thread safe pn_io_t
Key: PROTON-889
URL: https://issues.apache.org/jira/browse/PROTON-889
Project: Qpid Proton
Issue Type: Improvement
Components: proton-c
Reporter: Cliff Jansen
It has been pointed out before that the pn_io API does not allow thread safe
use of
pn_error_t *pn_io_error(pn_io_t *io)
bool pn_wouldblock(pn_io_t *io);
For the moment, this JIRA serves as a reminder. I am hesitant to propose a
specific solution without a solid outline of an actual implementation using it.
We have the following use cases:
- moderately scalable single threaded implementation using Proton's
selector/selectable classes
- custom selector/IO just using the Proton engine (i.e. Dispatch, Qpid C++
client/broker, no pn_io at all)
- external loop with direct calls to pn_io methods
The ultimate performance would come from the custom IO route optimized for the
particular work load using engine primitives. But given that Proton is (at
least mostly) thread safe on a per socket/connection basis (i.e. use by
Dispatch), it would seem that additional parallelization could be achieved with
various API changes (not just to pn_io methods).
So, again with the disclaimer that an actual implementation should drive this,
some options could be
6 new calls
pn_io_XXXX(io, selectable, buf, len); (send/recv/write/read)
pn_selectable_wouldblock(selectable);
pn_selectable_error(selectable);
4 new calls
pn_io_XXXX(io, socket, buf, len, bool *wouldblock, pn_error_t *err)
Assuming the existing single threaded use cases should not be burdened with
locking overhead, other related changes might include customized incref and
decref functions per pn_class_t, external custom collectors (and surely more).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
