rr, threads, and signal handlers
me at kylehuey.com
Tue Nov 3 03:49:17 UTC 2015
I suspect your theory is correct. We probably don't interrupt signal
handlers to do a thread context switch, and we definitely serialize
all threads to a single core, so busy waiting on thread 2 blocks
thread 1 from ever executing. We could probably trigger thread context
switches on long-running signal handlers.
On Mon, Nov 2, 2015 at 7:39 PM, Wade Hennessey <wadehennessey at gmail.com> wrote:
> I don't know if this list is the right place to ask a question about rr,
> pthreads and signal handlers, but it's the only place I've found.
> I have a program with 2 threads (but it could be an arbitrary number).
> Thread one at some point sends a signal to thread 2, and thread 2 has a
> signal handler that gets called. Thread 2 does a small amount of work and
> then busy waits for thread 1 to change the state of a global variable to
> indicate that it's ok to return from the signal handler.
> This program works fine without rr, but when I run try to rr record it, it
> hangs, seemingly because thread 1 never gets a chance to run and tell the
> signal handler on thread 2 that it's ok to return. Does rr require the
> signal handler on thread 2 to return before allowing thread 1 to run because
> of an rr limitation (i.e - everything runs on one core and signal handlers
> must return before any other thread can execute?).
> If there's a better place to ask this question, please let me know. The
> program in question could benefit immensely from rr if I can get it to work
> with rr record. -wade
> rr-dev mailing list
> rr-dev at mozilla.org
More information about the rr-dev