|Subject:||Re: [libmicrohttpd] Odd Stop Behavior|
|Date:||Thu, 26 Jun 2014 13:22:21 -0400|
On 06/07/2014 04:30 PM, Kenneth Mastro wrote:I doubt it as well.
> 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
You might want to check /proc/sys/net/ipv4/tcp_keepalive_time, just a
> 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.
random guess, though.
Right, but the interesting question is not where MHD_stop_daemon hangs,
> 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
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).
List is fine (if it's not megabytes ;-)), PM also. Whichever you're
> 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?
|[Prev in Thread]||Current Thread||[Next in Thread]|