Re: Escaping from blocked send() reprised.

Hello,

At Tue, 1 Jul 2014 21:21:38 +0200, Martijn van Oosterhout <kleptog@svana.org> wrote in
<20140701192138.GB20140@svana.org>
> 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.

Wow, thank you for detailed information. I'll study that and take
it into future discussion.

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

I guess it is for easiness-to-keep-compatibility, seems
reasonable.


have a nice day,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center