Path: utzoo!attcan!utgpu!watmath!att!tut.cis.ohio-state.edu!bloom-beacon!erik.UUCP!randy
From: randy@erik.UUCP (Randy Brown)
Newsgroups: comp.windows.x
Subject: Re: SysV, signals and X
Message-ID: <8909211509.AA05290@uunet.uu.net>
Date: 21 Sep 89 15:02:53 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 24

expo.lcs.mit.edu!keith (Keith Packard) writes:
> The problem with SysV is worse than you imagine.  Write(2) blocks when the
> receiver buffer fills up.  At this point, the signal may be processed, and the
> write(2) may return EINTR.  But, the client has no way of discovering how many
> bytes were written to the socket *before* the write was blocked and then
> interrupted.

My copy of the draft for comment of FIPS151-1, changes to IEEE 1003.1
POSIX, says in part:

In Section 6.4.2.2, the sentence "If a write() is interrupted by a signal
after it successfully writes some data, either it shall return -1 with
errno set to [EINTR] or it shall return the number of bytes written."
shall be deleted and replaced with the sentence "If a write() is
interrupted by a signal after it successfully writes some data, it shall
return the number of bytes the system has written."

So, as most major vendors like to sell to the feds, there's hope. Just
start now making clear that you want the FIPS POSIX version and not the
commercial POSIX version, which has a few more options to exercise that
can introduce incompatibility. For example, FIPS POSIX must support job
control (at the system call level), but IEEE POSIX has it optional.

Of course, this doesn't necessarily solve this week's problems. ... rb