0

On linux, I have a setup where I spawn off a profiler thread that blasts its parent thread with SIGPROF signals for a sampling profiler. I send the signal explicitly rather than relying on setitimer for better control. I may need to reconsider that, but for now assume I'm sending the signals myself.

My problem is that this sends signals all the time, even when the profiled thread is sleeping in a syscall. I get underruns on my sample ring buffer this way.

Is there some way to detect the run state of the profiled thread, even if it might change immediately after I check it? Or better yet, send a signal conditional on the target being in a running state?

I could sort of fake it by atomically incrementing a counter in the profiled thread's signal handler and checking whether it's changed from the profiler thread:

  volatile int samples;
  while(1) {
    int old_samples = samples;
    pthread_kill(profiled_thread, SIGPROF);
    while (samples == old_samples)
      usleep(appropriate amount);
  }

or something, but I'm wondering if there's a better way. (The above code simplifies the delay calculation, since really the whole point is to have unbiased samples, but ignore that for now.)

sfink
  • 1,726
  • 1
  • 17
  • 22

2 Answers2

0

I actually think interrupts during syscalls are a good thing, if you can sample the stack at that time, as in this post (points 7, 1). What's more, there's no particular value in getting a large number of samples (points 5, 9).

Community
  • 1
  • 1
Mike Dunlavey
  • 40,059
  • 14
  • 91
  • 135
0

There are couple problems that I see with the code.

1) Using volatile for variable samples doesn't warrant that you don't have race condition at from the time you assign it to old_samples to the while statement. Unless this is what you want, a stale value. ;-)

2) pthread_kill() seems a right way to send a signal to a specific thread. However, how do you know that it would be handled before another signal was sent in? How long is the queue signals? Could the signalled thread "signal" back (conditional wait of some sort) that it has processed the signal? Some sort of producer/consumer type pending signal variable?

eeerahul
  • 1,629
  • 4
  • 27
  • 38