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

2012-05-22 Thread Chet Ramey
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 th

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

2012-05-22 Thread Roman Rakus
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 rep

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

2012-05-22 Thread Chet Ramey
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

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

2012-05-22 Thread Roman Rakus
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 a

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

2012-05-22 Thread Greg Wooledge
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 sig

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

2012-05-22 Thread 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 you

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

2012-05-22 Thread Andreas Schwab
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.