You are viewing a plain text version of this content. The canonical link for it is here.
Posted to proton@qpid.apache.org by "Cliff Jansen (JIRA)" <ji...@apache.org> on 2015/05/22 22:36:17 UTC

[jira] [Created] (PROTON-889) Thread safe pn_io_t

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)