libmicrohttpd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libmicrohttpd] 0.9.53 breaks MHD_USE_POLL?


From: Lorenzo Miniero
Subject: Re: [libmicrohttpd] 0.9.53 breaks MHD_USE_POLL?
Date: Wed, 26 Apr 2017 10:56:25 +0200

2017-04-25 18:36 GMT+02:00 Evgeny Grin <address@hidden>:
Hi Lorenzo,

Thanks for report!
We introduced more checks in release 0.9.53 to make MHD more foolproof.
Now MHD reject invalid combinations of flags instead of starting with
undefined behaviour.
Applications are advised to set explicitly flag
MHD_USE_INTERNAL_POLLING_THREAD when using MHD_USE_THREAD_PER_CONNECTION.
Currently MHD_USE_THREAD_PER_CONNECTION flag also enforce implicit
setting of MHD_USE_INTERNAL_POLLING_THREAD.
I fixed check to improve backward compatibility with
MHD_USE_THREAD_PER_CONNECTION and MHD_USE_POLL without
MHD_USE_INTERNAL_POLLING_THREAD.

If application will be used with new version of MHD, I strongly advise
to use MHD_USE_AUTO instead of MHD_USE_POLL or MHD_USE_EPOLL (unless you
have specific reason to use poll() or epoll). With MHD_USE_AUTO you will
get best performance on any platform.

If you know any rejected valid combination of flags - let me know. We'll
probably make a bugfix release soon.



Hi Evgeny,

thanks for the quick response!

MHD_USE_AUTO does indeed seem to be the easiest fix, here, although it looks like a recent addition (last November?) and so might not be available in deployments that still ship an older version of the library. Adding MHD_USE_INTERNAL_POLLING_THREAD where MHD_USE_POLL is specified might do the trick too, but that also was only recently added. It is available on both my Fedora and on some 16.04 Ubuntu boxes we have (which are on 0.9.33), but not sure if the same can be said for all the people using our code at the moment, so I'll have to fix the code so that it can "adapt".

Using an #ifdef to see if those flags exist and react accordingly wouldn't work, as they're an enum and not defines. I guess that one way to do that without involving configure checks could be looking at MHD_VERSION: if it's higher than X, then we can use MHD_USE_AUTO, otherwise we do what worked for us so far. Not sure what X is, though: do you know the programmatic version number of when the feature was added?

Thanks!
Lorenzo

 
--
Best Wishes,
Evgeny Grin

On 24.04.2017 16:38, Lorenzo Miniero wrote:
> Hi all,
>
> I'm using MHD in my server and it works great. Recently I've been told,
> though, that some people couldn't get it to work. Somebody pointed out
> that it only seems to happen on recent versions, so I tried 0.9.53 (the
> latest on my Fedora) and that seems indeed to be the case.
>
> Specifically, by fiddling a bit with the code it looks like the cause of
> the failure is the MHD_USE_POLL. Check this sample test code as an example:
>
> https://gist.github.com/lminiero/5bd6795f2534b9c523c90603ec23816a
>
> The code as it is results in a failure for me (daemon=NULL). If I remove
> the MHD_USE_POLL, it works instead. The same code was definitely working
> on the previous version of MHD my Fedora shipped (0.9.46), but not sure
> if 0.9.53 itself is the cause or any version in between.
>
> At first I thought it could be a problem with flag names, as I read in
> the Changelog that some changed, but even in that case, the Changelog
> also says old names are still supported for backwards compatibilty.
> Besides, apparently MHD_USE_POLL is not one of the affected ones.
>
> I also considered the possibility that it may be an issue with how the
> Fedora 25 rpm was built, as MHD_USE_POLL is supposed to fail if poll()
> is not available (#ifndef HAVE_POLL) and so it might simply be a matter
> of a broken check there, but I'm not convinced that's it, as the same
> issue was reported on different distros (e.g., Arch Linux) and systems
> (Mac OS). So if it really is a broken check, it seems to be broken in
> more than one place.
>
> Do you have any insight on what may be the problem here?
>
> Thanks!
> Lorenzo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]