Path: utzoo!attcan!uunet!wuarchive!cs.utexas.edu!usc!bloom-beacon!EXPO.LCS.MIT.EDU!keith
From: keith@EXPO.LCS.MIT.EDU (Keith Packard)
Newsgroups: comp.windows.x
Subject: Re: SysV, signals and X
Message-ID: <8909201916.AA05996@xenon.lcs.mit.edu>
Date: 20 Sep 89 19:16:12 GMT
References: <2400@goanna.oz>
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 23


> However, in _XSend, which does a write() to the socket connected to the
> server, the interrupted system call error is not checked for and therefore
> the XIOErrorFunction will be called if the write() is interrupted.
> 
> How can you use signal() and your own signal handlers without the client
> generating an error message and exiting (because of the interrupted syscall)?

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.  If some data were sent to the server, the connection will become
hopelessly out-of-sync.  This is why the XIOErrorFunction is called when
write(2) return EINTR; the client cannot continue using the current display
connection.  Read(2) doesn't have this trouble as it returns either whatever
data is currently availible (without blocking) or waits for some data to
arrive.  When read(2) returns EINTR, no data could have been read yet.

The only solution on native SysV is to use something other than signals.

Keith Packard
MIT X Consortium