[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=15860622#comment-15860622 ] ASF subversion and git services commented on PROTON-1344: - Commit a96bccb23209f2bcf82ea6d3508ce4ac77316b99 in qpid-proton's branch refs/heads/master from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=a96bccb ] PROTON-1344: Add pn_proactor_t and pn_listener_t to > 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.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[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=15856767#comment-15856767 ] ASF subversion and git services commented on PROTON-1344: - Commit 66d8f0e9c493419f27ff63f47dd7a707efc28e80 in qpid-proton's branch refs/heads/go1 from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=66d8f0e ] PROTON-1344: Added missed PN_LISTENER_ACCEPT event from pn_event_type_name() > 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.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[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=15852097#comment-15852097 ] ASF subversion and git services commented on PROTON-1344: - Commit 66d8f0e9c493419f27ff63f47dd7a707efc28e80 in qpid-proton's branch refs/heads/master from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=66d8f0e ] PROTON-1344: Added missed PN_LISTENER_ACCEPT event from pn_event_type_name() > 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.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[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=15696675#comment-15696675 ] ASF subversion and git services commented on PROTON-1344: - Commit 6af49b819edb0d7d3aaa9968fc5ee1651f77f492 in qpid-proton's branch refs/heads/go1 from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=6af49b8 ] PROTON-1344: removed unused pn_listener_free, update proactor doc. > 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-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[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=15690563#comment-15690563 ] ASF subversion and git services commented on PROTON-1344: - Commit 6af49b819edb0d7d3aaa9968fc5ee1651f77f492 in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=6af49b8 ] PROTON-1344: removed unused pn_listener_free, update proactor doc. > 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-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[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=15674432#comment-15674432 ] ASF subversion and git services commented on PROTON-1344: - Commit bbeb096036ab67c88e8c33825aeab848605ae5c4 in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=bbeb096 ] PROTON-1344: proactor documentation updates > 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-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[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=15674428#comment-15674428 ] ASF subversion and git services commented on PROTON-1344: - Commit 94bc2965a8a39b04f3d85b4aa1cfb287b2fc2144 in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=94bc296 ] PROTON-1344: Fix proactor listen and broker examples for interop Added AI_PASSIVE to listener getaddrinfo() call, more correct and portable. Example broker default host is "::" which listens for IPv6 and IPv4 on same port on systems that allow that (IPV6ONLY defaults off) Note that IPv4-only systems will need to say `libuv_broker -a localhost` but since most modern systems support IPv6, that seems better than having clients simply fail to connect depending on whether they use localhost or ::1. > 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-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[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=15674430#comment-15674430 ] ASF subversion and git services commented on PROTON-1344: - Commit f2c8a3a38439c12d52dd93aed9173280c5754c9e in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=f2c8a3a ] PROTON-1344: proactor timeout support > 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-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[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=15674431#comment-15674431 ] ASF subversion and git services commented on PROTON-1344: - Commit aadfcbbb7a7b75eb442df4d4de8ef97eb2e7a754 in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=aadfcbb ] PROTON-1344: proactor listener/conneciton configuration Dropped extra bytes mechanism, may be re-introduced later. Added context and attachments to pn_listener_t, consistent with pn_connection_t Configure connection/listener before calling proactor connect/listen. Added PN_LISTENER_ACCEPT event so accepted connections can be configured. > 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-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[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=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: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[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=15674429#comment-15674429 ] ASF subversion and git services commented on PROTON-1344: - Commit 25706a47ea8f29c0a53f5fae44195a916173cfbd in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=25706a4 ] PROTON-1344: proactor batch events, rename connection_driver renamed pn_connection_engine as pn_connection_driver. pn_proactor_wait() returns pn_event_batch_t* rather than individual pn_event_t* to reduce thread-context switching. Added pn_collector_next() for simpler event looping. > 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-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[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=15664189#comment-15664189 ] ASF subversion and git services commented on PROTON-1344: - Commit 7bbd9f3046ba3c8c3e855836b105279ed0df641f 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=7bbd9f3 ] PROTON-1344: Fix proactor listen and broker examples for interop Added AI_PASSIVE to listener getaddrinfo() call, more correct and portable. Example broker default host is "::" which listens for IPv6 and IPv4 on same port on systems that allow that (IPV6ONLY defaults off) Note that IPv4-only systems will need to say `libuv_broker -a localhost` but since most modern systems support IPv6, that seems better than having clients simply fail to connect depending on whether they use localhost or ::1. > 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-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[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=15659280#comment-15659280 ] Adel Boutros commented on PROTON-1344: -- Hello Alan, I have a question: does this new development forces C++ 11? Or is it still supposed to work with C++03/98? Regards, Adel > 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-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[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=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-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
