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-27 01:11:49
Message-ID: 29744.1004145109@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:
> [ much ]

I think you are missing the point. I am not saying that we shouldn't
deal with EINTR; rather I am raising what I think is a legitimate
question: *what* is the most appropriate response? My reading of
HP's gloss suggests that we could treat EINTR the same as EINPROGRESS,
ie, consider the connect() to have succeeded and move on to the
wait-for-connection-complete-or-failure-using-select() phase.
If that works I would prefer it to repeating the connect() call,
primarily because it avoids any possibility of introducing an
infinite loop.

For PQrequestCancel we clearly do need to retry the connect(), since
that use of connect() isn't nonblocking. But I'm not convinced that
we should do so in the main-line connection code.

> It is possible with the current code for the
> connection to fail in non-blocking mode. Reason: you call connect() in
> non-blocking mode, break out of the section on EINPROGRESS, and continue
> assuming that the connection will be successful.

No, we don't. If you think that, then you haven't studied the code
sufficiently to be submitting patches for it. What we actually do
is exactly what is recommended by the manpage you're quoting at me.
It's just split across multiple routines.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2001-10-27 01:38:40 Re: 7.2b1 ...
Previous Message Lamar Owen 2001-10-27 01:04:54 Re: 7.2b1 ...