Subject: Re: Signal handling in tight loops
From: Mark Gordon <[email-masked]>
To: [email-masked]
Date: Wed, 15 Aug 2001 16:31:10 +0100

On Wed, 08 Aug 2001 13:57:03 -0400, "David A. Cobb"
<[email-masked]> wrote:

>At 8/7/01 08:28 PM (Tuesday), [email-masked] wrote:
>> > Wow.  You haven't been home for 24 hours?  I hope you're getting
>> > overtime.
>>
>>I was at home when I sent the question (some time around midnight, I
>>think), but it was here at work that I got your response.
>>
>>No matter.  Assuming that SIGALRM can't be raised inside loops of the
>>form,
>>
>>L1: jmp L1
>
>!! I hope that's a joke !!
>I haven't tried it on intel architecture, but on many processors there 
>would never be another read-next-instruction cycle, never another 
>interrupt, nothing at all until you pulled the plug.  Anyway, it isn't a 
>Cygwin issue - it's in the processor wiring/microcode.

On the processors I used to deal with the processor would still be
checking for interrupts in a loop like this. Mind you, I can't see
much use for this in normal software. In embedded systems I have done
something close...

loop: IDLE
      B    loop

as a background loop.

I just checked up on one of the old embedded 80x86 processors and it
is the instruction boundary, not the fetch which determines the
processor recognising interrupts.

>>what do you say to the idea of parsing the .s files for this sort of
>>pattern, and dealing with it there?

There should be no need because the processor should still respond to
interrupts as normal. Although why someone would do this in an
application is another matter.
-- 
Mark Gordon - To email me replace spamtrap with mark.gordon
	This message has been brought to you by the Flash AI Responder.
	No humans were harmed (or involved in any way) in its production.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/