We've noted in a few cases that wget can hang on connect() due
to a lack of any form of timeout management. We've made a change
to the routine connect_to_one in connect.c that will
implement a timeout mechanism on connect without the use of
signals or alarms. I've attached the modified version
Thomas Reinke [EMAIL PROTECTED] writes:
We've noted in a few cases that wget can hang on connect() due to a
lack of any form of timeout management. We've made a change to the
routine connect_to_one in connect.c that will implement a
timeout mechanism on connect without the use of signals or
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
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
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
On Wed, 19 Dec 2001, Hrvoje Niksic wrote:
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
Thomas Reinke [EMAIL PROTECTED] writes:
Again, I just never saw the point.
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,
I guess I was just lucky never to encounter
