You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "ASF subversion and git services (JIRA)" <ji...@apache.org> on 2016/11/12 06:22:58 UTC
[jira] [Commented] (PROTON-1344) Provide C "proactor" API for
multi-threaded proton applications
[ https://issues.apache.org/jira/browse/PROTON-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15659126#comment-15659126 ]
ASF subversion and git services commented on PROTON-1344:
---------------------------------------------------------
Commit 51d291b88731877e168e08d6316eb10cbf8bbf0e in qpid-proton's branch refs/heads/aconway-c-reactor from [~aconway]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=51d291b ]
PROTON-1344: C proactor for multi-threaded proton applications
proactor.h is an asynchronous, multi-threaded replacement for reactor.h
It uses the same Proton engine APIs and events, but allows multiple application
threads wait for events to handle, rather than calling back on handler functions
from a single thread.
The proactor ensures that events for the same AMQP connection are handled in
sequence (although possibly by different threads at different times) so event
handling code does not need to lock the use of thread-unsafe proton APIs. It
provides a "wake" feature to signal connections for processing triggered by the
application rather than proton IO.
Examples show C sender, receiver and broker, and a libuv driver implementation.
> Provide C "proactor" API for multi-threaded proton applications
> ---------------------------------------------------------------
>
> Key: PROTON-1344
> URL: https://issues.apache.org/jira/browse/PROTON-1344
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-c
> Reporter: Alan Conway
> Assignee: Alan Conway
> Fix For: 0.16.0
>
>
> This work will pull together work that has been going on with the experimental pn_connection_engine_t and work on a new C multi-threaded libuv C driver. This work has matured to the point of putting together a coherent and complete pn_proactor API to (eventually) replace the pn_reactor.
> The big differences:
> - proactive not reactive: e.g. void proactor_connect() does not return a bound connection, it starts an asynchronous connection process. All results are reported asynchronously as events, not as synchrouns return values.
> - application controls threading: application thread(s) call wait() to block for events. There are no callbacks to application code from unknown threading contexts.
> - enforces threading model to ensure that events from one connection engine are only handled in one thread at a time. The application does not need locks to or tables to manage this.
> - provides simple inter-thread singalling - any thread can "wake" a connection, causing the proactor to return an event in a thread-safe way for application-triggered work.
> The big similarities:
> Same proton protocol engine API is unchanged - the pn_connection_engine will dissappear as a separate entity but it's functions will be folded back into pn_connection and pn_transport.
> Same event model: existing code that processes events is unchanged, instead of registering `void my_handler(pn_event_t *)` with the reactor, the application calls my_handler(pn_driver_wait()) in its own threads. There will be a handful of new proactor-related events.
--
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