[PATCH] Fix ETIME handling for Solaris event ports

[Jeremy Allison]

On Thu, Feb 04, 2016 at 10:33:30PM +0100, Ralph Boehme wrote:
> On Thu, Feb 04, 2016 at 01:32:51PM -0800, Jeremy Allison wrote:
> > On Wed, Feb 03, 2016 at 03:24:48PM -0700, Nathan Huff wrote:
> > > Turns out EINTR is even more messed up than ETIME.  It is possible to not
> > > get an event and not have nget updated either so you have to actually check
> > > the event structure you get back.  I have attached an updated patch to deal
> > > with that situation as well.
> > 
> > Reviewed-by: Jeremy Allison <jra at samba.org>
> > 
> > Nice work Nathan, good catch.
> > 
> > Can I get a second Team reviewer ?
> 
> Nack, I'm not convinced this is the correct fix. The EINTR handling
> still seems wrong.

Well I did look at that very carefully.

The statement above is very clear -

"It is possible to not get an event and not have nget updated
either so you have to actually check the event structure you get back."

Given that the patch handles this correctly.

It checks for ret == -1, then in the EINTR case
it only calls the signal handler if events[0].portev_source == 0
(which means no event was received) and ev->signal_events != NULL.
If events[0].portev_source == 0 (meaning no
fd event was received) then we always return.

If events[0].portev_source != 0 then it goes into
the event handling loop, as we got an fd event.

As nget doesn't get changed on EINTR (so remains as 1)
the only way to ensure an event *wasn't* receieved
is to check events[0].portev_source hasn't changed.

If an fd event was received, but it returned EINTR
(meaning we also got a signal) we must process the
fd event first and not the signal handler otherwise
we'll lose the event association.

The signal handler will then be called on the next
call into port_event_loop_once().

So yeah, this patch does look right to me. What am I
missing ?

Jeremy.