Re: Possible bug: Race condition when calling external commands during trap handling

[Linda Walsh]

Andreas Schwab wrote:

> A trap is not a signal.  It doesn't "come in".  A trap handler is
> executed because some condition is true at a command boundary.
>
> Andreas.

That still begs the question...

If you are in your trap handler, and you don't reset the signal --
how can you guarantee that your signal handler will be reset
before another even that would cause a trap occurs -- say a child
dying.  If you don't have a trap in place and a child dies, do you
lose the indication that a child died?  Suppose 2 die and now you install your
trap handler, will you get a second call to your trap handler immediately upon
exit from the first?

    I honestly don't know how bash would handle some of these things.

I do know that the input subsystem can drop keys when it switches
from raw to cooked.  I don't know if it should, but it happens if
you use something like  drops keys when you switch modes alot
like calling
> more testin
#!/bin/bash
stty raw
if read -n1 -t0 char; then
  stty cooked
  read -n1 -t1 char
  echo "($char)"
else
  stty cooked
  echo "(undef)"
fi
repetitively from a perl script (perl's mechanism for doing this never times out
and returns if a  sigwinch comes in...)...so amusingly, it's safer (though a bit 
flakey) to periodically call a shell script to poll the keyboard...  ;-)...

But the point is, real time events are a pain to get right -- if you don't want 
to lose traps corresponding to interrupts, in perl and C, at least, you need to 
reset the event handler before returning from processing the current event.

But bash may be different...I was just warning of the possibility of their being 
a problem NOT doing it in the handler, as such exists in many other similar 
handlers.