|
From: Jeremy F. <je...@go...> - 2005-05-31 22:16:34
|
Josef Weidendorfer wrote:
>I have a question on Valgrind scheduling (I have a bug here in my tool): as
>callgrind has "shadow" call stacks for each thread, it always needs to know
>which thread currently is running. Usually, this is no problem with
>VG_(track_thread_run).
>
>I also track signal handlers. And these can switch the running thread.
>VG_(track_thread_run) is not called directly after a signal handlers return.
>So the question is, what thread is resumed when a signal handler returns? Do
>I have to track this myself? And if, how to do this?
>Can there be a thread switch while a signal handler is running?
>
>
In general, signals do not explicitly cause thread context switches. A
thread may become runnable because it received a signal, but it is no
different from any other reason a thread may become runnable (like a
syscall unblocking). Likewise, returning from a signal doesn't
explicitly cause a thread context switch.
A signal handler isn't special in any way, so there's always a chance
you can get a context switch in a signal handler.
What problem are you seeing?
J
|