Re: "Interrupted system call" in C lib even with mp:without-interrupts CL 8.1

Frank Goenninger DG1SBG <dont-email-me@xxxxxxxxxx> writes:

[Frank, I don't do customer support over c.l.l - you should indeed
report the issue to support@xxxxxxxxx for your particular issue.
However, since there are general operational questions here which can
be answered here in a general way, I'll do so, without necessarily
dealing with the specifics of your situation. ]

"josephoswald+gg@xxxxxxxxx" <josephoswald@xxxxxxxxx> writes:

On Nov 27, 3:07 pm, Frank Goenninger DG1SBG <dont-email...@xxxxxxxxxx>
"Interrupted system call" in C lib even with mp:without-interrupts
AllegroCL 8.1, Mac OS X

Interrupted system call is a completely kind of interrupt than
mp:without-interrupts is protecting against.

Hmmm - so how would one read this bit from the ACL manual:


Arguments: &body body

This macro executes body, protecting against any handling of
asynchronous interrupts. Execution of body is guaranteed to complete
without any other process running, or any asynchronous interrupt
being dispatched, unless the process does something to block or
otherwise explicitly yield to the scheduler (e.g. with

Note that this paragraph does _not_ say that the async signals are
blocked - only that they are not acted upon, or dispatched. It is
dangerous to block signals for any significant length of time, so the
mechanism that we use to handle async signals is a simple handler
called "gotsig" - it receives the signal, logs it in a small buffer,
and a flag is set that the lisp code can query and then dispatch the
action at the appropriate time. Obviously, this does not happen
within a without-interrupts form.

Interrupted system calls are a UNIXy feature, signified by the C
return code EINTR. They mean your task got a UNIX signal delivered to
it, or something equivalent, while it was blocking in the system

Yeah. Of course (15 years of HP-UX system programming experience on my
side speaking here ;-)

Unfortunately (:-) we have over 30 years (and many times that, in
man-years) of experience over at least 10 different Unix flavors of
operating system, and with respect to signals, the picture is not very
pretty; signals are a global resource (a very bad situation) and they
are not even regularized as to which signal is generated for any
particular situation (perhaps surprisingly, the most diverse of these
is the software-generated traps, which actually do not tend to
generate SIGTRAP, as expected, but usually generate something else,
such as SIGSEGV or SIGILL).

As for interrupted calls, we have been able on most systems to
standardize on the most regular of signal handling specifications,
sigaction(). This function allows the SA_RESTART flag to be set in
order to automatically restart the system call after the interrupt has
been received. It is possible that the particular signal you're
receiving does not have that bit set, or it may be an operating system
for which we don't use sigaction, for one reason or another. You'll
have to send a message to support@xxxxxxxxx to initiate a conversation
on the specifics.

I don't know the details of AllegroCL, but that without-interrupts
call is probably intended to protect the integrity of your data
against the actions of other threads and/or processes.

So it's about time to ask the Franz wizards on why the Lisp code gets
interrupted but my simple C program does the job jolly well.

Yes, absolutely.

Duane Rettig duane@xxxxxxxxx Franz Inc.
555 12th St., Suite 1450
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182