signal handling effeciency ?
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
52 24902 [main] readtest 3208 sig_send: returning 0x0 from sending
45 24947 [main] readtest 3208 readv: readv (3, 0x22C880, 1) blocking,
46 24993 [main] readtest 3208 readv: no need to call ready_for_read
45 25038 [main] readtest 3208 readv: 1024 = readv (3, 0x22C880, 1),
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...
Lead Realtime Software Engineer
VITAL - Visual Simulation Systems
the best safety device in any aircraft is a well-trained crew...
More information about the Cygwin-developers