[
https://issues.apache.org/jira/browse/PROTON-1734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16370416#comment-16370416
]
Alan Conway edited comment on PROTON-1734 at 2/20/18 6:29 PM:
--------------------------------------------------------------
I think this is a proactor behavior problem.
In stop(), C++ uses pn_proactor_interrupt() to close all open
connctions/listeners etc. and then waits for a PN_PROACTOR_INACTIVE event
before closing down. This is the intended use of the proactor.
The problem is that the proactor currently only dispatches the
PN_PROACTOR_INACTIVE event on the *transition* from active to inactive - i.e.
when the last connection, listener or timeout finishes. Therefore if you call
pn_proactor_disconnect() when the proactor is already inactive, you will never
get a PN_PROACTOR_INACTIVE event.
I think a valid fix is to say that the proactor should *always* dispatch at
least one PN_PROACTOR_ACTIVE event after every call to
pn_proactor_disconnect(). If there are things to disconnect, then the INACTIVE
is dispatched as it currently is when the last activity is finished. If not it
is dispatched immediately.
was (Author: aconway):
I think this is a proactor behavior problem.
In stop(), C++ uses pn_proactor_interrupt() to close all open
connctions/listeners etc. and then waits for a PN_PROACTOR_INACTIVE event
before closing down. This is the intended use of the proactor.
The problem is that the proactor currently only dispatches the
PN_PROACTOR_INACTIVE event on the *transition* from active to inactive - i.e.
when the last connection, listener or timeout finishes. Therefore if you call
pn_proactor_disconnect() when the proactor is already inactive, you will never
get a PN_PROACTOR_LISTEN event.
I think a valid fix is to say that the proactor should *always* dispatch at
least one PN_PROACTOR_ACTIVE event after every call to
pn_proactor_disconnect(). If there are things to disconnect, then the INACTIVE
is dispatched as it currently is when the last activity is finished. If not it
is dispatched immediately.
> [cpp] container.stop() doesn't work when called from non-proactor thread.
> -------------------------------------------------------------------------
>
> Key: PROTON-1734
> URL: https://issues.apache.org/jira/browse/PROTON-1734
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
> Affects Versions: proton-c-0.19.0
> Reporter: Alan Conway
> Assignee: Andrew Stitcher
> Priority: Major
> Fix For: proton-c-0.21.0
>
>
> Using the below code
> {code}
> #include <proton/container.hpp>
> #include <iostream>
> #include <thread>
> int main( int, char** )
> {
> try
> {
> proton::container c;
> c.auto_stop( false );
> auto containerThread = std::thread([&]() { std::cout << "CONTAINER IS
> RUNNING" << std::endl;
>
> c.run(); std::cout << "CONTAINER IS DONE" << std::endl; });
> std::this_thread::sleep_for( std::chrono::seconds( 2 ));
> std::cout << "STOPPING CONTAINER" << std::endl;
> c.stop();
> std::cout << "WAITING FOR CONTAINER" << std::endl;
> containerThread.join();
> return 0;
> }
> catch( std::exception& e )
> {
> std::cerr << e.what() << std::endl;
> }
> return 1;
> }
> {code}
> via
> {code}
> [rkieley@i7t450s build]$ g++ -g -Wall -Wextra -Wpointer-arith -Wconversion
> -Wformat -Wformat-security -Wformat-y2k -Wsign-promo -Wcast-qual -g3 -ggdb3
> -Wunused-variable -fno-eliminate-unused-debug-types -O3 -DNDEBUG -fPIC
> -DPN_CPP_HAS_LAMBDAS=0 -std=gnu++11 ../attachments/test.cpp
> -lqpid-proton-cpp -lqpid-proton-core -lqpid-proton-proactor -lrt -lpthread -o
> test
> {code}
> With both PROACTOR epoll and libuv I see the following when run:
> {quote}
> [New Thread 0x7ffff3c95700 (LWP 20312)]
> CONTAINER IS RUNNING
> STOPPING CONTAINER
> WAITING FOR CONTAINER
> ^C
> Thread 1 "test" received signal SIGINT, Interrupt.
> {quote}
> When I use CTRL-C to stop waiting after running via gdb and waiting 2 minutes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
