concurrent thread pool fixed when spinning in a loop forever

[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]

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]

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]

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

[zarnce]

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]

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]

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]

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