This is the mail archive of the cygwin-patches@cygwin.com 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.


On Tue, Aug 19, 2003 at 09:06:45PM -0400, Pierre A. Humblet wrote:
>At 08:37 PM 8/19/2003 -0400, Christopher Faylor wrote:
>>On Tue, Aug 19, 2003 at 04:30:06PM -0400, Pierre A. Humblet wrote:
>>>Regarding your changes (it will take me a while to fully understand them)
>>>- What problem are you trying to solve by having a local sigtodo?
>>>  Specifically now that you have removed the thisproc argument in
>sig_handle,
>>>  rc is not used in any function call and I don't see why it's helpful
>>>  to segregate signals on a per source basis. 
>>
>>>On Tue, Aug 19, 2003 at 12:22:17AM -0400, Christopher Faylor wrote:
>>>>Oh, right.  I was remembering a time when the inner while used to
>>>>exhaust the InterlockedDecrement.  It doesn't do that anymore but that
>>>>hardly matters because, as you say, it is possible to the current code
>>>>to be confused by "simultaneous" signals coming from the outside and
>>>>from the current process.
>>>>
>>>>The only way I can think of around that is to add another an internal
>>>>sigtodo array to every process just for signals sent to myself and scan
>>>>that and the sigtodo process table.  I guess I'll implement that in the
>>>>next couple of days.
>
>Yep. But the 'confusion by "simultaneous" signals' was due to
>thisproc which was set to "rc == 2"

No.  The confusion could result from two signals coming in at the nearly
the same time, one from an external source and one from internal.  In
that case wait_sig had no way of telling which signal was which and
could end up either not setting a completion event or setting it
erroneously.

>Now that you have gotten rid of that I don't see any confusion
>left and I don't see the reason for the local sigtodo.
>
>>>- Having low_priority_sleep (SLEEP_0_STAY_LOW) in the sigthread loop 
>>>  leaves it running (and WFMOing) at low priority. 
>>
>>How is moving it into the sigthread loop any different than having it
>>where it was previously?  The point was for the sigthread loop to
>>take a nap for a while and give the main thread a chance to wake up.
>
>For two reasons:
>- Taking a nap is not useful if the mainthread is waiting for
>a semaphore from the sigthread. The nap should occur after the
>semaphore has been signaled.

I think we're talking about different things.  The only thing I did was
move the existing code out of setup_handler and into wait_sig.  There
should be very little functional difference in doing this.

As I said previously, I am going to have to dissect your patch and look
at it in more detail.  I haven't done that yet.  I thought you were
implying that my move caused a functional difference.  If you want,
I'll remove the "suggested by Pierre Humblet" from the ChangeLog.

>>>Also, as you wrote the signal code is not as simple as a bicycle! A
>>>question I have is why it's helpful to call
>>>thisframe.call_signal_handler in sig_dispatch_pending.  I was under the
>>>impression that something like it would happen automagically on return.
>>
>>Not necessarily.  It depends on who is calling sig_dispatch_pending.  An
>>outer sigframe user wins.  This guarantees that signals will be
>>dispatched in sig_dispatch_pending.
>
>Thanks, but it's still greek to me. What is an "outer sigframe user".

Someone who calls sigframe earlier in the call stack.

cgf


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