Re: Signal handling in tight loops

Re: Signal handling in tight loops

[ejrh]

> 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

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



--
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/

Re: Signal handling in tight loops

[David A. Cobb]

At 8/7/01 08:28 PM (Tuesday), ejrh@paradise.net.nz 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.


>what do you say to the idea of parsing the .s files for this sort of
>pattern, and dealing with it there?
>
>
>
>--
>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/

David A. Cobb, Software Engineer, Public Access Advocate, All around nice guy.
Get my PGP key at
:< http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=superbiskit >
Fingerprint=0x{6E3E_DB8C_2E8C_4248_62B2_FE29_08EE_CF0A_3629_E954}
:< http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=superbiskit&fingerprint=on >
"By God's Grace I am a Christian man, by my actions a great sinner."
--The Way of a Pilgrim, R. M. French [tr.]
Potentially Viral Software is any software for which you are not allowed
to examine the source.  Do not buy or use Potentially Viral Software!
<---.----!----.----!----.----!----.----!----.----!----.----!----.---->


--
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/

Re: Signal handling in tight loops

[Mark Gordon]

On Wed, 08 Aug 2001 13:57:03 -0400, "David A. Cobb"
<superbiskit@home.com> wrote:

>At 8/7/01 08:28 PM (Tuesday), ejrh@paradise.net.nz 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/

Re: Signal handling in tight loops

[ejrh]

> 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

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



--
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/

Re: Signal handling in tight loops

[Christopher Faylor]

On Tue, Aug 07, 2001 at 11:33:07PM +0000, ejrh@paradise.net.nz wrote:
>> Why don't you write a simple test case?
>
>Because I am at work where I don't have cygwin, or any compiler of any 
>form for that matter.

Wow.  You haven't been home for 24 hours?  I hope you're getting overtime.

>> This technique should be much more useful than inviting random opinions
>> from a mailing list and it should be MUCH faster.
>
>I've only had one random opinion so far.  :)

Which sorta proves my point.

cgf

--
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/

Re: Signal handling in tight loops

[ejrh]

> Why don't you write a simple test case?

Because I am at work where I don't have cygwin, or any compiler of any 
form for that matter.

> This technique should be much more useful than inviting random opinions
> from a mailing list and it should be MUCH faster.

I've only had one random opinion so far.  :)

Original question:
> > the alarm signal could not be raised in very tight loops, because
> > signals were only checked when memory was accessed.  Does this apply
> > to cygwin, by any chance?



--
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/

Re: Signal handling in tight loops

[Christopher Faylor]

On Tue, Aug 07, 2001 at 11:06:45PM +1200, Edmund Horner wrote:
>Hello again.
>
>From my DJGPP days I remember that the alarm signal could not be raised
>in very tight loops, because signals were only checked when memory was
>accessed.  Does this apply to cygwin, by any chance?
>
>The reason I'm asking is that I have a module in my program which I
>can't completely trust, and I'd like to terminate it after 2 minutes if
>it hasn't returned by then.  I'm hoping to use alarm() for this.
>
>Feasible?

Why don't you write a simple test case?

This technique should be much more useful than inviting random opinions from
a mailing list and it should be MUCH faster.

cgf

--
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/

Signal handling in tight loops

[Edmund Horner]

Hello again.

From my DJGPP days I remember that the alarm signal could not be raised
in very tight loops, because signals were only checked when memory was
accessed.  Does this apply to cygwin, by any chance?

The reason I'm asking is that I have a module in my program which I
can't completely trust, and I'd like to terminate it after 2 minutes if
it hasn't returned by then.  I'm hoping to use alarm() for this.

Feasible?



--
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/