Synchronous signals vs. robust code

[Peter Milliken]

I interrupted (rightly or wrongly :-)) the following as desiring some form
of timely responsiveness to signals:

"However, it is still unsatisfactory in that it results in the signal
being delayed for an arbitrary amount of time; if a time-critical
signal happens during the try-block, we will not process it until
much later."

Perhaps Mark didn't mean what he says here? So what is his definition of
"time-critical"? :-) You don't get my definition of "time-critical"
satisfied by any interpreted language - but perhaps we operate in different
"ball parks". Certainly if he means "time-critical" to some user pounding on
a keyboard then Python is certainly sufficient for the job! :-)

"Paul Rubin" <phr-n2002a at nightsong.com> wrote in message
news:7xy9hridd1.fsf at ruckus.brouhaha.com...
> "Peter Milliken" <peter.milliken at gtech.com> writes:
> > Why not use a language that provides your requirements of signal safety
etc
> > and do a Python API for it? (assuming one doesn't exist) i.e. I find it
> > somewhat difficult to reconcile your statement about responding to time
> > critical signals when you propose use of an interpretive language.....
:-)
> > Sounds like you would ideally like real-time language features in a
language
> > that isn't designed for it (well, I'm not sure Guido had visions of
Python
> > being used in real-time applications :-)).
>
> I don't see anything real-time specific in that post.  It's a generic
> problem.  I don't see a clean way to make sure your 'finally' clauses
> execute if the user hits ^C several times while the program is
> running.  Early versions of Unix didn't have reliable signals either,
> and it led to flaky programs, til BSD Unix fixed it.