Re: [patch] helps fe-connect.c handle -EINTR more gracefully

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Ford <david(at)blue-labs(dot)org>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [patch] helps fe-connect.c handle -EINTR more gracefully
Date: 2001-10-26 21:29:09
Message-ID: 28636.1004131749@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Ford <david(at)blue-labs(dot)org> writes:
> Thus a simplified loop should look like this:

No, it should *not* look like that. The fe-connect.c code is designed
to move on as soon as it's convinced that the kernel has accepted the
connection request. We use a non-blocking connect() call and later
wait for connection complete by probing the select() status. Looping
on the connect() itself would be a busy-wait, which would be antisocial.

Certainly we can move on as soon as we see EINPROGRESS or EALREADY.
What I'm wondering at the moment is whether we could take EINTR to be
also an indication that the kernel has accepted the connection request,
and proceed forward to the select(), rather than trying the connect()
again.

Although Brent didn't say so very clearly, I think his real concern is
"why are you getting EINTR from a non-blocking connect, and what does
that mean anyway?" The HPUX man page certainly makes it sound like
this is not distinct from the EINPROGRESS return, and that there's
no need to retry the connect() per se.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2001-10-26 21:36:08 Re: [patch] helps fe-connect.c handle -EINTR more gracefully
Previous Message Peter Eisentraut 2001-10-26 21:04:39 Re: [patch] helps fe-connect.c handle -EINTR more gracefully