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

["Justin Ross (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/PROTON-889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Justin Ross updated PROTON-889:
-------------------------------
    Labels: close-pending  (was: )

> 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
>              Labels: close-pending
>
> 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)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org