From: Frank Goenninger DG1SBG
Subject: "Interrupted system call" in C lib even with mp:without-interrupts CL 8.1
Date:
Message-ID: <lzbq9f311x.fsf@de.goenninger.net>
"Interrupted system call" in C lib even with mp:without-interrupts
AllegroCL 8.1, Mac OS X
Hi all again:
I am doing I/O via USB and an external C library for communication
handling to talk to a power meter (for HF power and standing wave
ratio measurements). One particular task is to upload new firmware to
the device.
Uploading the firmware is a critical task and takes some 50 seconds
when done directly using a command line utilty written in C to drive
comm lib. It is critical that the upload process doesn't get
interrupted - the device will be in a state requiring a power down /
power on cycle - not good for a remote location ...
So I load the lib via CFFI and calling the less time consuming tasks
get executed as expected. During the longer operation of uploading
firmware the select() call the comm lib does for waiting for data on
the serial device file gets interrupted.
I tried wrapping the call in mp:without-interrupt and
mp:without-scheduling ... no success.
Anybody out there with experience in such matters?
I'd also be able to use LispWorks or SBCL though I haven't tried yet
(LW is nasty for using Celtk on OS X - some COCOA based issue with
thread 0 ... oh my)
Thanks for any pointers!!
Appreciate your patience ... ;-)
Frank
--
Frank Goenninger
frgo(at)mac(dot)com
"Don't ask me! I haven't been reading comp.lang.lisp long enough to
really know ..."
On Nov 27, 3:07 pm, Frank Goenninger DG1SBG <·············@nomail.org>
wrote:
> "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.
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 call.
See for example http://www.madore.org/~david/computers/connect-intr.html
or one of W. Richard Stevens' books on UNIX programming.
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.
From: Frank Goenninger DG1SBG
Subject: Re: "Interrupted system call" in C lib even with mp:without-interrupts CL 8.1
Date:
Message-ID: <lz63zmlrnc.fsf@de.goenninger.net>
················@gmail.com" <············@gmail.com> writes:
> On Nov 27, 3:07 pm, Frank Goenninger DG1SBG <·············@nomail.org>
> wrote:
>> "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:
without-interrupts
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
mp:process-allow-schedule).
> 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
> call.
Yeah. Of course (15 years of HP-UX system programming experience on my
side speaking here ;-)
> 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.
Thanks for sharing.
Frank
--
Frank Goenninger
frgo(at)mac(dot)com
"Don't ask me! I haven't been reading comp.lang.lisp long enough to
really know ..."
From: Duane Rettig
Subject: Re: "Interrupted system call" in C lib even with mp:without-interrupts CL 8.1
Date:
Message-ID: <o0ejea5q51.fsf@gemini.franz.com>
Frank Goenninger DG1SBG <·············@nomail.org> writes:
[Frank, I don't do customer support over c.l.l - you should indeed
report the issue to ·······@franz.com 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. ]
> ················@gmail.com" <············@gmail.com> writes:
>
>> On Nov 27, 3:07 pm, Frank Goenninger DG1SBG <·············@nomail.org>
>> wrote:
>>> "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:
>
> without-interrupts
>
> 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
> mp:process-allow-schedule).
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
>> call.
>
> 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 ·······@franz.com 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 ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
From: Frank Goenninger DG1SBG
Subject: Re: "Interrupted system call" in C lib even with mp:without-interrupts CL 8.1
Date:
Message-ID: <lzwss2we0l.fsf@de.goenninger.net>
Duane Rettig <·····@franz.com> writes:
> Frank Goenninger DG1SBG <·············@nomail.org> writes:
>
> [Frank, I don't do customer support over c.l.l - you should indeed
> report the issue to ·······@franz.com 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. ]
I appreciate your answer here. I posted my reply this morning Central
European Time (9 hours difference to Bay Area time) and got hit by
customer activities before writing a relating mail to Franz
support. Sorry for the delay ...
>
>> ················@gmail.com" <············@gmail.com> writes:
>>
>>> On Nov 27, 3:07 pm, Frank Goenninger DG1SBG <·············@nomail.org>
>>> wrote:
>>>> "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:
>>
>> without-interrupts
>>
>> 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
>> mp:process-allow-schedule).
>
> Note that this paragraph does _not_ say that the async signals are
> blocked - only that they are not acted upon, or dispatched.
Which I interprete as "delivery is delayed until leaving the body form
of mp:without-interrupts".
> 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.
I would then be looking for a hook into that one.
>>> 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
>>> call.
>>
>> 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).
I had been lucky to be able to concentrate on just one vendor, HP
(which I worked for for more than 12 years). Nevertheless, I had the
means at my fingertipps to react on, block, etc any type of signal
besides a few core ones.
>
> 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.
I will investigate. OS here is OX X 10.4.11.
> You'll
> have to send a message to ·······@franz.com 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.
Will do so in a few hours. I just got a customer call I have to react
to ...
Thx a lot, Duane!!!
Frank
--
Frank Goenninger
frgo(at)mac(dot)com
"Don't ask me! I haven't been reading comp.lang.lisp long enough to
really know ..."
From: Frank Goenninger DG1SBG
Subject: SOLVED !! - Was: Re: "Interrupted system call" in C lib even with mp:without-interrupts CL 8.1
Date:
Message-ID: <lzhcj4px40.fsf_-_@pcsde001.de.goenninger.net>
Frank Goenninger DG1SBG <·············@nomail.org> writes:
> Duane Rettig <·····@franz.com> writes:
>
>> [Frank, I don't do customer support over c.l.l - you should indeed
>> report the issue to ·······@franz.com 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. ]
Problem solved: timing issue. Problem in C land, not in Lisp.
I had to tweak the timeouts for the select() call a little to get
stable behaviour. I've never seen this before: different timings
on the same machine (I had factored in that there are different
runtime situations because the total set of processes obviously
varies over time) - but now I have seen that the Lisp runtime env
of that one process just acts a bit differently timewise. So I
made all my timeouts into variables I can tweak ... Easy. Now
that part runs as desired.
Duane fired a series of questions at me and I did get quite some
"there has to be a simple reason and a simple solution" kick from
those questions - in the end I saw what to do because Duane made me
look!
And it was not an Allegro CL related problem at all ... Thanks again
for a superb, directed, responsive support from Franz.
Frank
--
Frank Goenninger
frgo(at)mac(dot)com
"Don't ask me! I haven't been reading comp.lang.lisp long enough to
really know ..."
From: Frank Goenninger DG1SBG
Subject: Re: SOLVED !! - Was: Re: "Interrupted system call" in C lib even with mp:without-interrupts CL 8.1
Date:
Message-ID: <lzbq9a2p3v.fsf@pcsde001.de.goenninger.net>
Frank Goenninger DG1SBG <·············@nomail.org> writes:
> Frank Goenninger DG1SBG <·············@nomail.org> writes:
>
>> Duane Rettig <·····@franz.com> writes:
>>
>>> [Frank, I don't do customer support over c.l.l - you should indeed
>>> report the issue to ·······@franz.com 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. ]
>
>
> Problem solved: timing issue. Problem in C land, not in Lisp.
>
> I had to tweak the timeouts for the select() call a little to get
> stable behaviour. I've never seen this before: different timings
> on the same machine (I had factored in that there are different
> runtime situations because the total set of processes obviously
> varies over time) - but now I have seen that the Lisp runtime env
> of that one process just acts a bit differently timewise. So I
> made all my timeouts into variables I can tweak ... Easy. Now
> that part runs as desired.
>
> Duane fired a series of questions at me and I did get quite some
> "there has to be a simple reason and a simple solution" kick from
> those questions - in the end I saw what to do because Duane made me
> look!
>
> And it was not an Allegro CL related problem at all ... Thanks again
> for a superb, directed, responsive support from Franz.
Additiional info - just in case anyone is seeing this also:
The original code segment was:
nSelectResult = select( nFD + 1,
&nReadFDs,
&nWriteFDs,
&nExceptFDs,
&sTimeVal );
Now I do:
void vBlockSignal( int nSignalNr )
{
sigset_t nBlockSignalSet;
sigemptyset( &nBlockSignalSet );
sigaddset( &nBlockSignalSet, nSignalNr );
sigprocmask( SIG_BLOCK, &nBlockSignalSet, NULL );
return;
}
void vUnblockSignal( int nSignalNr )
{
sigset_t nBlockSignalSet;
sigemptyset( &nBlockSignalSet );
sigaddset( &nBlockSignalSet, nSignalNr );
sigprocmask( SIG_UNBLOCK, &nBlockSignalSet, NULL );
return;
}
and:
// set signal set to be ignored durin select()
vBlockSignal( SIGALRM );
// Wait for data
nSelectResult = select( nFD + 1,
&nReadFDs,
&nWriteFDs,
&nExceptFDs,
&sTimeVal );
vUnblockSignal( SIGALRM );
This solved the problem.
frgo
--
Frank Goenninger
frgo(at)mac(dot)com
"Don't ask me! I haven't been reading comp.lang.lisp long enough to
really know ..."
Frank Goenninger DG1SBG wrote:
>
> Uploading the firmware is a critical task and takes some 50 seconds
> when done directly using a command line utilty written in C to drive
> comm lib. It is critical that the upload process doesn't get
> interrupted - the device will be in a state requiring a power down /
> power on cycle - not good for a remote location ...
>
I see that you have solved the issue.
But, this raised a few questions in my mind that I'd like to get some
understanding on.
If you are saying that I am allowed to write an app that disallows the
OS from interrupting it at all for 50 seconds doesn't that mean there is
a very easy way to make a denial of service thingy.
Just random thought. But I'd like to understand what I am
misunderstanding (would appreciate an answer from anyone)
Thanks.
-a.s
From: Frank Goenninger DG1SBG
Subject: Re: "Interrupted system call" in C lib even with mp:without-interrupts CL 8.1
Date:
Message-ID: <lz1wa52xwl.fsf@pcsde001.de.goenninger.net>
lisp linux <·········@lisp.linux> writes:
> If you are saying that I am allowed to write an app that disallows the
> OS from interrupting it at all for 50 seconds doesn't that mean there is
> a very easy way to make a denial of service thingy.
> Just random thought. But I'd like to understand what I am
> misunderstanding (would appreciate an answer from anyone)
> Thanks.
> -a.s
Well, if you have access to the C compiler then yes, you can do almost
anything on a *nix-based system (kernel modules and device drivers being
exceptions AFAIK because they require special installation steps) in
your *own* app. You will not block/kill any other application.
It's in the responsibility of the programmer to make sure that you do
not introduce application instability in any way. If you try to make
Malware then that's another thing.
Concerning DoS: If you are blocking all signals from being handled -
maybe. I've never tried that. So the normal approach is to find out
which signal is causing problems and block this one signal for the
shortest time possible. See my other post: SIGALRM blocked before
select() and unblocked right after select(). This is still *your*
*own* *app* - not any other app.
strace/ktrace/dtruss are your friends to find out which signal you
have to block/unblock.
So - back to Lisp now ;-)
- frgo
--
Frank Goenninger
frgo(at)mac(dot)com
"Don't ask me! I haven't been reading comp.lang.lisp long enough to
really know ..."