[
https://issues.apache.org/jira/browse/PROTON-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15674427#comment-15674427
]
ASF subversion and git services commented on PROTON-1344:
---------------------------------------------------------
Commit ca454180b2846b2538a60ad03a047aa6a738d3ca in qpid-proton's branch
refs/heads/master from [~aconway]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=ca45418 ]
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: [email protected]
For additional commands, e-mail: [email protected]
