Re: Timeout for connect()
From: David Schwartz (davids_at_webmaster.com)
Date: 03/01/04
- Next message: Pascal Bourguignon: "Re: Available memory"
- Previous message: Jo: "Re: Timeout for connect()"
- In reply to: Jo: "Re: Timeout for connect()"
- Next in thread: Jo: "Re: Timeout for connect()"
- Reply: Jo: "Re: Timeout for connect()"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 29 Feb 2004 17:43:51 -0800
"Jo" <JoJoTwilligo@hotmail.com> wrote in message
news:72ce7f0c.0402291555.493fd62e@posting.google.com...
>> You can't. It could depend upon any number of factors that you don't
>> know. Why do you think you need to know this?
> Because I would want to know the maximum amount of time connect()
> would block for.
There is no way to know. In general, an application has no way to know
how long a network protocol will take to complete a task or fail at it.
>> > Also, I've heard that you can use SIGALARM (with the help of
>> > alarm()) to cancel a blocking function like connect(), but what I
>> > don't quite get is how to use the handle. I've read that I need to
>> > write a handler for SIGALARM, but how does such a handler affect
>> > connect()? I've also read that I set the handler to SIG_IGN. I don't
>> > believe everything I read.
>>
>> You can set the handler to SIG_IGN. The signal will be ignored, but
>> it
>> will cause 'connect' to return before the connection completes or fails.
>> The
>> connection will still be in process when 'connect' returns EINTR. You can
>> call 'connect' later to find if it sucfeeded or fail.
>
> Oh yeah? Don't I run the risk of some kind of leak? Say, a
> connection or socket leak?
I'm not sure what you're talking about. You only run the risk of a leak
if you don't close the things you open.
> I'm also a bit surprised at how simple it
> would be to write non-blocking code. I avoided the solution that
> involves select(), because it was too complicated for my
> implementation. From what I'm hearing here, I could do something like
> this:
>
> do {
> alarm(1);
> } while (connect(who, &cares, question_mark) == -1 && errno == EINTR);
> alarm(0);
Just don't forget to ignore SIG_ALARM. I think you have this wrong
though. The second call to 'connect' will fail with EINPROGRESS.
> Each call to connect() here will go back to the first call's
> connection context and not create a new one? If that's so, why does
> the solution to a non-blocking connect() in the faq have that
> complicated code involving a select()?
You have your code wrong. Your second call to 'connect' will fail
immediately because a connection is already in progress.
Can you state your actual problem? Odds are the solution has nothing
whatsoever to do with connection timeouts. What's the problem you have? What
are you trying to do?
DS
- Next message: Pascal Bourguignon: "Re: Available memory"
- Previous message: Jo: "Re: Timeout for connect()"
- In reply to: Jo: "Re: Timeout for connect()"
- Next in thread: Jo: "Re: Timeout for connect()"
- Reply: Jo: "Re: Timeout for connect()"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|