Re: [patch] helps fe-connect.c handle -EINTR more gracefully - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [patch] helps fe-connect.c handle -EINTR more gracefully
Date
Msg-id 28636.1004131749@sss.pgh.pa.us
Whole thread Raw
In response to Re: [patch] helps fe-connect.c handle -EINTR more gracefully  (David Ford <david@blue-labs.org>)
List pgsql-hackers
David Ford <david@blue-labs.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


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: schema support, was Package support for Postgres
Next
From: Tom Lane
Date:
Subject: Re: [patch] helps fe-connect.c handle -EINTR more gracefully