Re: Escaping from blocked send() reprised.

Hello,

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