This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Signal handling tune up.

At 12:13 AM 8/19/2003 -0400, Christopher Faylor wrote:
>I may not be able to get to your patch soon since I have actual
>honest-to-gosh Red Hat Cygwin duties to attend to for the first time
>in quite some time.  I volunteered to help out on a cygwin project even
>though I've moved from the group that is responsible for cygwin.  I
>neglected those duties tonight, in fact, thanks to the excitement of
>someone actually submitting substantial signal handling patches.  :-)

No problem, sorry to keep you awake! Some thoughts came to my mind 
during the night, don't know if they are still relevant after your

>Are you saying that that someone reported execing a process, hitting
>ctrl-c, and having another process simultaneously sending CTRL-C's to
>the exec'ed stub?  

The thisproc argument in sig_handle was only used to handle that exec'ed
stub. Couldn't that condition be detected reliably in handle_exceptions(),

>I only applied the reversal of the movl with the call above since I'm
>not convinced that moving the set_process_mask into interrupt_setup
>doesn't introduce a race. 

Don't we have the same problem today?

Handler is running with current mask M1, old mask M0
New signal occurs, sigthread prepares sigsave with new mask M2, old mask M1
 but is preempted before setting sigsave.sig
Handler terminates, restores M0
sigthread resumes and starts new handler. It runs with M2 and restores
M1 (instead of M0) at end.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]