Re: [libmicrohttpd] 0.9.53 breaks MHD_USE_POLL?

[Lorenzo Miniero]

2017-04-26 13:39 GMT+02:00 Evgeny Grin <address@hidden>:

On 26.04.2017 13:54, Lorenzo Miniero wrote:
> Thanks! So, just to clarify, when doing MHD_USE_THREAD_PER_CONNECTION,
> even with MHD_USE_AUTO you still need to specify
>  MHD_USE_SELECT_INTERNALLY (or the newer
> MHD_USE_INTERNAL_POLLING_THREAD), or does MHD_USE_AUTO also
> automatically sets the correct threading model? Asking because the way
> I was addressing this in a pull request on my project was simply to do a:
>
> #if MHD_VERSION >= 0x00095208
> MHD_USE_THREAD_PER_CONNECTION | MHD_USE_AUTO | MHD_USE_DUAL_STACK,
> #else
> MHD_USE_THREAD_PER_CONNECTION | MHD_USE_POLL | MHD_USE_DUAL_STACK,
> #endif
>
> which seems to be working as expected on 0.9.53.
>
It better to specify MHD_USE_SELECT_INTERNALLY explicitly.
If it is not specified, MHD_USE_THREAD_PER_CONNECTION will use
MHD_USE_SELECT_INTERNALLY implicitly.

Version 0.9.53 fails with poll and without MHD_USE_SELECT_INTERNALLY
because check of invalid combinations of flags is done *before* adding
automatically MHD_USE_SELECT_INTERNALLY.
It was fixed in git master.

I recommend you to always use MHD_USE_SELECT_INTERNALLY when you specify
MHD_USE_THREAD_PER_CONNECTION.

Or use predefined combination of flags:

#if MHD_VERSION >= 0x00095208
MHD_USE_THREAD_PER_CONNECTION | MHD_USE_AUTO_INTERNAL_THREAD |
MHD_USE_DUAL_STACK,
#else
MHD_USE_THREAD_PER_CONNECTION | MHD_USE_POLL_INTERNALLY |
MHD_USE_DUAL_STACK,
#endif

Tnx, I'll update the PR to make this explicit!

 

I also recommend to use MHD_USE_DEBUG flag when you developing
something. Actually, it is not a "debug", it is a "log".

Yep, I found out about this when looking at the docs and I tried adding that when I wanted to find out what was causing the daemon creation failure, although nothing was printed out. In fact, no logging is done during the creation process apparently, at least by looking at the code. I guess MHD_USE_DEBUG is definitely useful after that, so when handling requests and to monitor what happens internally by looking at the logs. I'll keep this in mind as an additional configuration setting we can expose.

Cheers,

Lorenzo