jkh@pcsbst.UUCP (jkh) (04/03/89)
Yes, I'm beginning to run into that same 'ol SysV problem yet again. Namely,
non-restartable system calls. This has probably already been noticed
by those vanilla SYSV folks who wanted to use xtrek, and somehow got the
setitimer stuff to work under sysV, but were rewarded by about 10 milliseconds
of program execution time before seeing "XIO Error.... (croak)"
In my case, I'm not doing something even a fraction as signal intensive,
it's just the timing between two operations dealing with the SIGCHLD
from a dying process and the output from it I'm in the process of
printing. Process Death results.
Now, I'm looking at the code in Xlibint.c and it looks like EINTR is
handled correctly for all the *Read() operations, but not the Write
ops. This all jibes with my coredumps and I have to wonder exactly
why this is so. Is it just because the Xlib is not designed in such
a way as to allow a postponed write? I can certainly understand how
it's a lot easier to handle the failure case for reads than writes.
Still, at the least, I would think it appropriate to AT LEAST block
all the signals before the write() call in the WriteToServer() macro
and then release them again. I'm tempted to make this change in
our Xlib, but would (of course) much rather see an MIT approved fix.
In the meantime, I'm forced to block/unblock the offending signal(s)
around EVERY Xlib call. Can you say "Heeaaaavvveeeeee...."?
I knew you could.
Jordan
--
--------
Jordan Hubbard
PCS Computer Systeme GmbH
West Germany
UUCP: {uunet,decwrl}!pyramid!pcsbst!jkh
ARPA: jkh@violet.berkeley.edu
"I'd like a burrito please."
"Was?"
"Uh. Ich moechte ein Mexicanische 'Burrito', bitte."
"Hahahahahahaha.. Das ist ein guter Witz. Du bist toll.."
"Hey! It's real easy, just take some cheese, some meat and
some beans and roll it up like this.."
"Raus!"