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.


Christopher Faylor wrote:

> >I was planning to also eventually propose patches for the  following,
> >but it's more efficient to tell Chris while he is working on the code
> >and before I forget:
> >1) sigcatch_nosync could be an event instead of a semaphore. This
> >   doesn't affect the logic and will cut down useless loops, mainly
> >   at high load with pending_signals set.
> 
> Are you seeing a lot of loops through the signal handler due to
> semaphores being > 1?

Yes, in heavy traffic. That's what made me think of this.

> >2) When a signal is pending but blocked, pending_signals is set and
> >   sig_dispatch_pending() signals the sigthread. It would be more
> >   efficient to have a pending_signal_mask and to do mask comparison
> >   in sig_dispatch_pending(). It's just a courtesy call, no interlock
> >   is necessary.
> 
> There are all sorts of optimizations like this which could be done. 

I proposed those two because they are straightforward and will have 
an impact.
 
> Do you think that an occasional loop through the signal handler is slowing
> things down that much?  Do you think that sig_dispatch_pending gets
> called a lot with all pending signals blocked?  Are you convinced that
> you can set a mask in a non-raceable way?

Yes in heavy traffic, and it contributes the the trashing phenomenon
I saw with SIGALRM (system has to work even more in heavy load).

Races in sig_dispatch_pending() could occur because either a) the mask 
changes, or because b) pending_signal_mask changes. 
a) isn't a problem in the long run because with pthreads a mask can only 
be changed by its thread (there is no process mask). 
Races can occur with b), but races already occur today with pending_signals.
That's not a problem because sig_dispatch_pending() is a "good will" call, 
it can afford to have an occasional miss or a false alarm.

I am also starting to look at the relation with pthread and signals.
I noticed that sigactions are currently per thread, which isn't Posix. 
An immediate fix is to change "getsig (int sig)" in pinfo.h, you will
need to touch it anyway when you pull the sigactions out of pinfo.
Also I haven't yet found the private sigtodo for the main thread, nor
its mask.
Trying to imagine a possible implementation, I think it would help to have
per thread sigsave's, to avoid failed interrupts when delivering signals
to several threads.

Pierre


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