Re: [libmicrohttpd] Odd Stop Behavior

[Christian Grothoff]

On 06/07/2014 04:30 PM, Kenneth Mastro wrote:
> Hi Christian,
> 
> Thanks for the quick reply.
> 
> And erk!  Sorry about the OS thing.  I'm on Linux.  My development
> environment is a stock install of Ubuntu 12.04 LTS VM on a Windows 7 PC.
> (I doubt the VM thing matters at all, but figured I'd mention it just in
> case.)

I doubt it as well.

> Here's my MHD_start_daemon code, nothing earth shattering ( I assume that's
> where the per-connection timeout would be set):
> -----------------------
> myDaemon = MHD_start_daemon(MHD_USE_THREAD_PER_CONNECTION, // one thread
> per connection
>                                 WEB_TEST_PORT,                 // port to
> listen on
>                                 nullptr,                       // accept
> policy callback
>                                 nullptr,                       // extra arg
> to accept policy callback
>                                 &connectionCallbackC,          // main
> 'connection' callback
>                                 this,                          // extra
> argument to the 'connection' callback
>                                 MHD_OPTION_NOTIFY_COMPLETED,   // specifies
> that the next arg is the callback to call when the connection is done
>                                 &requestCompletedCallbackC,    // the
> callback to call when the connection is done
>                                 this,                          // extra arg
> to the callback when the connection is done
>                                 MHD_OPTION_CONNECTION_LIMIT,   // specifies
> that the next arg is the max number of simultaneous connections
>                                 (unsigned int)20,              // the
> number of permitted simultaneous connections
>                                 MHD_OPTION_END);               // no more
> options in the arg list
> ----------------------
> 
> So - no timeout changes for MHD.  I haven't changed the default timeout for
> the kernel, so I'm guessing that 115 (awfully close to 120, i.e., 2
> minutes) is something else?  I agree completely that it's likely some kind
> of timeout, though.

You might want to check /proc/sys/net/ipv4/tcp_keepalive_time, just a
random guess, though.

> I don't change any thread timeouts at all (although I have some other
> threads in my application that I set to real-time priority for some audio
> processing, but I can't imagine how that would adversely affect MHD).
> 
> If I didn't mention it before, I did trace this down to the 'join' of the
> thread in 'close_all_connections'.  I assume 'MHD_join_thread_' is actually
> pthread_join since I'm on Linux.  My gut was telling me that somehow the
> thread isn't being told to stop as part of the shutdown process and is
> eventually just timing out somewhere inside MHD (or via TCP as you
> suggested).

Right, but the interesting question is not where MHD_stop_daemon hangs,
but what that other thread is doing at the time
(gdb threads, thread #NUM, ba; alternatively, strace -f BINARY to see
what system call returns after 120s might also help a bit...).

netstat -ntpl to see if some connection somehow is still open might also
be useful (alternatively, lsof -p).

> Before I noticed this problem, I was running with
> 'MHD_USE_SELECT_INTERNALLY' with a thread-pool, but you had suggested in a
> previous post (a few weeks ago) that that won't work properly with
> 'comet-like' requests unless I do the suspend/resume functionality.  That's
> perfectly fine and good, but it seems worth mentioning that I didn't notice
> this problem when using that thread mode.  From looking at the
> 'close_all_connections' code in daemon.c, I can see why the behavior could
> be different.
> 
> 
> Anyway - I'll play around with the HAVE_LISTEN_SHUTDOWN option, see if that
> makes any difference.  Failing that, I'll see if I can create a test case.
> That make take a couple days, though - lots of code to strip out to keep it
> simple.  What should I do once I get a concise test case ready to go?  Send
> the code to the mailing list?

List is fine (if it's not megabytes ;-)), PM also. Whichever you're
comfortable with.

Happy hacking!

Christian