Daniel Stenberg <[EMAIL PROTECTED]> writes: > On Wed, 19 Dec 2001, Hrvoje Niksic wrote: > >> But one problem with this implementation is portability -- I'm pretty sure >> that some systems don't support FIONBIO. > > Correct. Ancient ones it seems, I couldn't find a single "modern" > (eh, no don't ask me to define that term) system that doesn't do it > FIONBIO-style.
Wget aims to compile on non-modern systems too. (I won't attempt to define it either, but let's say that for the sake of this discussion I consider Ultrix to be fairly modern.) >> Implementing the same feature in Wget should probably require more >> investigation and a lot of testing on different platforms. > > Hm. First, would that really be so bad? For me personally, it might not be easy. These days I only have access to Linux and Solaris, and perhaps Digital Unix. I have almost no access to old or weird systems. Maybe the situation is different with someone else, but I somehow doubt it. > Secondly, why not "downgrade" to blocking connects if you couldn't > figure out how to do non-blocking ones? I suppose that's a possibility. Or we could just use FIONBIO which works on "modern" systems, and turn off connect timeouts for others. >> So far I've been consistently reaching the conclusion that connect >> timeouts are simply not worth the effort. > > You could solve it with a plain and simple alarm() and a signal > handler. It would work on pretty much all unix-systems... That's true. Again, I just never saw the point. I assume you didn't do that in libcurl because you didn't want to muck around with signals from within the library?
