Re: Escaping from blocked send() reprised. - Mailing list pgsql-hackers

From Martijn van Oosterhout
Subject Re: Escaping from blocked send() reprised.
Date
Msg-id 20140701192138.GB20140@svana.org
Whole thread Raw
In response to Re: Escaping from blocked send() reprised.  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Responses Re: Escaping from blocked send() reprised.  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
List pgsql-hackers
On Tue, Jul 01, 2014 at 12:26:43PM +0900, Kyotaro HORIGUCHI wrote:
> > 1. I think it's the case that there are platforms around where a
> > signal won't cause send() to return EINTR.... and I'd be entirely
> > unsurprised if SSL_write() doesn't necessarily return EINTR in that
> > case.  I'm not sure what, if anything, we can do about that.
>
> man 2 send on FreeBSD has not description about EINTR.. And even
> on linux, send won't return EINTR for most cases, at least I
> haven't seen that. So send()=-1,EINTR seems to me as only an
> equivalent of send() = 0. I have no idea about what the
> implementer thought the difference is.

Whether send() returns EINTR or not depends on whether the signal has
been marked restartable or not. This is configurable per signal, see
sigaction(). If the signal is marked to restart, the kernel returns
ERESTARTHAND (IIRC) and the libc will redo the call internally.

Default BSD does not return EINTR normally, but supports sigaction().

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> He who writes carelessly confesses thereby at the very outset that he does
> not attach much importance to his own thoughts.  -- Arthur Schopenhauer

pgsql-hackers by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: RLS Design
Next
From: Abhijit Menon-Sen
Date:
Subject: Re: replication commands and log_statements