Re: Possible bug: Race condition when calling external commands during trap handling
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. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Possible bug: Race condition when calling external commands during trap handling
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.
Re: Possible bug: Race condition when calling external commands during trap handling
On Tue, May 22, 2012 at 04:47:01AM -0700, Linda Walsh wrote: > 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 You are using the wrong words for everything. A signal is an asynchronous event, potentially sent by another process. A signal handler is a bit of code that you write, and then register to be executed when you receive a signal. A trap is the same as a signal handler. ''trap'' is the name of the bash command to register a signal handler (assigning it to a set of signals). I do not know the answers to "How does bash implement traps? Is there a guarantee that no signals will be lost?" Hopefully someone else does. The man page has only a partial answer. Under JOB CONTROL: Any trap on SIGCHLD is executed for each child that exits.
Re: Possible bug: Race condition when calling external commands during trap handling
On 05/22/2012 02:28 PM, Greg Wooledge wrote: I do not know the answers to "How does bash implement traps? Is there a guarantee that no signals will be lost?" Hopefully someone else does. I can just imagine a situation when the bash is reading trap from the source (is going through the script and is on line where trap is) or not read it yet and the signal is received. Then, of course, your trap handler is not installed yet. Another situation: You had previous trap handler and you are installing new one. The received signals are "paused" for a while and are processed right after the installation of new trap handler. There was a bug report against this, I'm not sure if it is fixed. RR
Re: Possible bug: Race condition when calling external commands during trap handling
On 5/22/12 8:41 AM, Roman Rakus wrote: > Another situation: You had previous trap handler and you are installing new > one. The received signals are "paused" for a while and are processed right > after the installation of new trap handler. There was a bug report against > this, I'm not sure if it is fixed. Can you provide a reference to that report? -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Possible bug: Race condition when calling external commands during trap handling
On 05/22/2012 03:01 PM, Chet Ramey wrote: On 5/22/12 8:41 AM, Roman Rakus wrote: Another situation: You had previous trap handler and you are installing new one. The received signals are "paused" for a while and are processed right after the installation of new trap handler. There was a bug report against this, I'm not sure if it is fixed. Can you provide a reference to that report? http://lists.gnu.org/archive/html/bug-bash/2011-04/msg00045.html RR
Re: Possible bug: Race condition when calling external commands during trap handling
On 5/22/12 9:16 AM, Roman Rakus wrote: > On 05/22/2012 03:01 PM, Chet Ramey wrote: >> On 5/22/12 8:41 AM, Roman Rakus wrote: >> >>> Another situation: You had previous trap handler and you are installing new >>> one. The received signals are "paused" for a while and are processed right >>> after the installation of new trap handler. There was a bug report against >>> this, I'm not sure if it is fixed. >> Can you provide a reference to that report? >> >> > http://lists.gnu.org/archive/html/bug-bash/2011-04/msg00045.html According to the bash change log, it was fixed three days later. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
