> > 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?
FWIW, as I mentioned to Hrvoje earlier off-line, it can be a reliability issue. Without it, wget can hang and require some form of intervention to terminate properly, and that type of termination will result in the entire "mirroring process" (or whatever you are doing) aborting early. Personally, I like the idea of supporting non-blocking connects where the technology supports it, and for others, well, they'll have to live with the current behaviour. It seems sort of a shame though to force everyone to use the lowest common denominator. (And hey, I hate patching software for our own use - I'd rather just fix the bug and use the standard distro :)) Cheers, Thomas
