libmicrohttpd
[Top][All Lists]
Advanced

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

Re: [libmicrohttpd] Remove PlibC from autotools files


From: Christian Grothoff
Subject: Re: [libmicrohttpd] Remove PlibC from autotools files
Date: Thu, 08 Aug 2013 21:00:07 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130704 Icedove/17.0.7

On 08/08/13 20:50, Michael Cronenworth wrote:
On 08/08/2013 01:15 PM, LRN wrote:
What if timeout is set not to 5 seconds, but more... ? Now you get the idea.

Please do not insult me. (I took this as one)

I'm sure no insult was intended.

PlibC does the same operation but wakes up 1/10th a second no matter what your
timeout is set to.

Which is very ugly, but nobody has really suggested anything better AFAIK. I don't like the idea of throwing extra threads at this, as
I suspect that'll have other unpleasant effects --- for starters by
making the W32 and POSIX implementations diverge even further, rather than making them closer.

If you want to bring in an entire library for something that could take a dozen
lines of code then I can't stop you.

Well, the question is how big plibc really is. For non-W32 systems, it is nothing, as everything is just #define'd away. For W32, it's supposed to do as little as possible to make things work as on POSIX. Now, I still would like to get rid of it, but IIRC the 'select' loop was always the biggest and messiest part of PlibC, and the UTF-8 conversion stuff really hardly matters for MHD either way. So given the choice of duplicating the (messy) select loop and keeping it at arms length, I'd rather not duplicate it. What I had hoped was that somehow recent MinGW systems had fixed 'select', but I guess that was overly optimistic on my part.

I wish you guys the best of luck. A rotten experience on my end.

Look, for me the point is that I like the MHD code to look as clean as possible. That W32 select hack is a big mess, with 5s or 100ms doesn't matter in terms of ugliness -- but 100ms is certainly more tolerable as an "extra" shutdown delay (call it the W32-penalty). But that is not an argument against your patch per-se. The real question is if we can do something to make select on W32 work nicely on MinGW, so we don't have the busy waiting crap to begin with.

In any case, the whole point started with a plibc licensing issue, which AFAIK has been resolved (or is close to), so I'm not quite sure I see why you're that frustrated, as at least the primary issue is being addressed.

Happy hacking!

Christian




reply via email to

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