signal handling effeciency ?

Brian Ford
Mon Jul 24 19:30:00 GMT 2006

I've been trying to debug a scenario under which network file reads become
particularly slow in an application with HIGH_PRIORITY_CLASS threads.  I
haven't gotten very far yet, but I ran across this curious scenario with

   46   24527 [main] readtest 3208 sig_dispatch_pending: flushing
   45   24572 [main] readtest 3208 sig_send: sendsig 0x6E4, pid 3208,
signal -34, its_me 1
   54   24626 [main] readtest 3208 sig_send: wakeup 0x6F4
   49   24675 [main] readtest 3208 add_handle: protecting handle
'pack.wakeup'(0x6F4), inherited flag 0
   60   24735 [main] readtest 3208 sig_send: Waiting for pack.wakeup 0x6F4
   62   24797 [sig] readtest 3208 wait_sig: signalling pack.wakeup 0x6F4
   53   24850 [main] readtest 3208 delete_handle: nuking handle
'pack.wakeup' (0x6F4)
   52   24902 [main] readtest 3208 sig_send: returning 0x0 from sending
signal -34
   45   24947 [main] readtest 3208 readv: readv (3, 0x22C880, 1) blocking,
sigcatchers 0
   46   24993 [main] readtest 3208 readv: no need to call ready_for_read
   45   25038 [main] readtest 3208 readv: 1024 = readv (3, 0x22C880, 1),
errno 0

Is the event create, wait for signal thread, event destroy sequence per
read call by design?  That ping-pong per system call seems like a lot of
overhead.  If you have any general idea about how to avoid this, I might
be interested in creating and testing a patch.

Trying to revive and enhance what little understanding I previously
had of the signal handling code...

Brian Ford
Lead Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained crew...

More information about the Cygwin-developers mailing list