Re: io_close proposal

[Marcus Brinkmann]

On Thu, May 16, 2002 at 04:29:49PM -0400, Roland McGrath wrote:
> > I am not sure I agree with this.  POSIX says that if the program
> > receives a signal during close(), close() should return with -1 and
> > errno set to EINTR, and the state of the filedescriptor that was about
> > to be closed is undefined.
> 
> Well, how about that.  But actually it says "unspecified", which is
> different.  (I'm looking at POSIX.1-1996.)  I'm not exactly sure what
> latitude we have here.  That is, options that are semantically different
> from either as if no close call was made or as if close completed normally.

Ah yes, unspecified, not undefined.  The difference is that undefined
behavious is the result of invalid code, and unspecified behaviour the
result of valid code.  This does not seem tell us anything about the result of
the code, though, eg if the filedescriptor must be in a specified state.

> It never makes sense to interrupt if you don't care to synchronize.

Ok, thanks for the hint about SIGKILL.  Makes sense.

> If you
> were SIGKILL'd you wouldn't send the interrupt to any servers, so they have
> to be prepared to cope.  If the synchronization blocks can ever take very
> long, then the server might want to interrupt_self_on_port_death.

Ah, for the reply port, right?  (I still have to spell out such trivialities ;)
Yeah, that would help in the case I was worrying about.

> > The way I read POSIX, we are not even allowed to restart the operation,
> > but we must (POSIX says "shall") return -1/EINTR.  But I only checked
> > the definition of close() so far, not if SA_RESTART overrides this.
> 
> I think you are probably right about this.

I have checked again.  POSIX seems to give SA_RESTART a blanket job of
restarting everything that is interruptible and would return EINTR.  It
doesn't really look like close() would be an exception to this.  (There is
nothing that says that it would be an exception, and the lack of saying
explicitely that SA_RESTART should restart close() is consistent with the
lack of saying it for most interruptible functions -- and there are many of
them, more than I thought!).

> The question is whether, if the
> appropriate synchronization has not happened, we are required to leave the
> descriptor open (as if close had never been called).

I agree that this is the real question for us here, very well put.  It will
be more work in the server if we have to make this guarantee.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org address@hidden
Marcus Brinkmann              GNU    http://www.gnu.org    address@hidden
address@hidden
http://www.marcus-brinkmann.de