Hello Stephane et al., My goal is to have an arbitrary number of threads monitor themselves, each being interrupted after approximately 1ms worth of clock cycles have gone by. Libpfm's example program self_smpl_multi seemed to do something similar, so I rewrote it to take an arbitrary number of threads and an arbitrary number of desired interrupts per second.
I followed self_smpl_multi's technique of arranging to receive a SIGIO in the thread associated with the Perfmon context, landing in the registered signal handler. The threads continue running until they've reached the targeted number of interrupts. For example, 10 interrupts/second times five seconds of runtime would be 50 total interrupts. This approach works fine up to about 25 interrupts/thread/second on my Intel Core2 Quad (4 core) system. After that, some of the threads never stop. Peering at the program in GDB leads me to believe that one or more threads doesn't get SIGIO anymore. My current guess is that if any one thread is handling SIGIO, any new notifications on other threads just get dropped on the floor; the descriptor doesn't get read, so the signal handler doesn't get invoked anymore. Would real time signals help me here (to queue up the signals), or is there some other approach to thread interruption I should explore? Thanks in advance for your time and help. -john ------------------------------------------------------------------------------ Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
