This is the mail archive of the cygwin-developers 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: Can you undo change in sig_dispatch_pending() ?


On Wed, Oct 31, 2007 at 01:40:36PM -0500, Brian Ford wrote:
>On Wed, 31 Oct 2007, Christopher Faylor wrote:
>
>> Of course updating a single variable could conceivably not be racy.  We
>> are talking about a separate thread which does all sorts of things to
>> the variable, however, like preparing to update it, for instance.  It really
>> is possible that the "sig" thread can be in the process of updating sigq
>> while sig_dispatch_pending is in the process of testing it.
>
>Yes, but it is also possible that it could be updating it just after
>sig_dispatch_pending tested it.  So?

If the intent of the test is to deal with signals that are pending and a
signal is pending but not yet in the linked list that would indicate
that there is a race.

>> If you have tests for this then you can either try removing the
>> sig_dispatch_pending entirely and see how that works
>
>I think I explained why that isn't a good idea, no?

If the sigq.next test can't do a perfect job then it would sort of stand
to reason that the test may not actually be necessary at all.

>> or you can generate data showing how often the sigq.start.next test is
>> triggered and report the results here.
>
>I'd like to understand what you meant by that more.  Did you mean how
>often does it avoid the needless thread ping pong, or how often does it
>actually invoke it?  I assume the latter as the performance data clearly
>indicates the former is very frequent.

I mean how many times

  if (!sigq.next)
     return;

  /* this code */

is executed.

cgf


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