concurrent thread pool fixed when spinning in a loop forever #168

Closed
wants to merge 3 commits into
from

Projects

None yet

3 participants

@matthewaveryusa

In stop_listen, having the acceptor call close() before the join was causing handle_accept to loop with the following sequence of errors:

Starting WebSocket sleep server on port 9003 with thread pool size 2 and 2 worker threads.
2012-12-17T23:51:11 [8192] role::server listening on port 9003
2012-12-17T23:51:11 [8192] Connection created: count is now: 1
start_accept called
adding listening thread
adding listening thread
//-----> m_acceptor.close() called here
joining listening threads
2012-12-17T23:51:11 [16] async_accept returned error: system:125 (io_service operation canceled)
2012-12-17T23:51:11 [8192] terminate called from state: 0
2012-12-17T23:51:11 [8192] terminate removing connection
2012-12-17T23:51:11 [8192] Connection removed: count is now: 0
2012-12-17T23:51:11 [8192] Connection created: count is now: 1
start_accept called
2012-12-17T23:51:11 [16] async_accept returned error: system:9 (unknown)
2012-12-17T23:51:11 [8192] terminate called from state: 0
2012-12-17T23:51:11 [8192] terminate removing connection
2012-12-17T23:51:11 [8192] Connection removed: count is now: 0
2012-12-17T23:51:11 [8192] Connection created: count is now: 1
start_accept called
(repeat the previous 6 lines forever)

system:9, on my debian machine is from /usr/include/asm-generic/errno-base.h and corresponds to:

define EBADF 9 /* Bad file number */

I'm thinking it means that socket is closed at this point?

This may not be exactly what you want (I haven't studied the code base enough), but moving the m_acceptor.close() fixes the issue.

Thanks for the great work, this is a wonderful alternative to node and I'm looking forward to contribute/work with this a lot more!
-Matt

@zaphoyd zaphoyd added a commit that referenced this pull request Dec 19, 2012
@zaphoyd corrects an infinite loop when the acceptor is closed in thread pool …
…mode references #168
6a1dccc
@zaphoyd
Owner
zaphoyd commented Dec 19, 2012

I've added an alternate, hopefully more robust, solution that has the accept loop detect whether or not the acceptor is still open and if not stop trying to accept connections on the dead socket. Can you let me know if this fixes your issue?

@zarnce
zarnce commented Dec 28, 2012

I have the latest commit checked out and am getting the 125 error. Any idea when a fix will found?

@matthewaveryusa

try 6e6d637 with all of the trace in and let me know your output is. 796e0b1 is exactly the same but without the trace.

@zarnce
zarnce commented Dec 31, 2012

I built with 6e6d637 and everything appears to work. I must have had a build problem. Sorry about that.

@zarnce
zarnce commented Jan 3, 2013

I tried the actual fix put into master and I still get the 125 error.

Thanks
Brian

@matthewaveryusa

Indeed, The fix put in master doesn't fix the problem. You need to get zaphoyd's attention since he is the only one that can add the commit to master.

@zaphoyd zaphoyd added a commit that referenced this pull request Jan 4, 2013
@zaphoyd Updates multithreaded non-forked listen methods to not prematurely cl…
…ose the endpoint. references #168
5809440
@zaphoyd
Owner
zaphoyd commented Jan 4, 2013

Okay, the latest two commits should implement a fix similar to 6e6d637. listen(...) called with num_threads > 1 shouldn't cause the endpoint to immediately close its acceptor and perpetually be in the stop listening state. I can't remove join from stop_listen as that would break other things, but i've moved join within stop listen so that all threads must be joined before the acceptor is closed. I've successfully tested this with the concurrent server example program. Can anyone else confirm that this fixes the issue?

@zarnce
zarnce commented Jan 4, 2013

I built with the latest 5809440 and everything seems to be working. Other than not getting the 125 error I'm not sure how to confirm the fix.

@zaphoyd
Owner
zaphoyd commented Apr 18, 2013

I believe this is fixed now, if not, please reopen.

@zaphoyd zaphoyd closed this Apr 18, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment