rr, threads, and signal handlers

Robert O'Callahan robert at ocallahan.org
Tue Nov 3 04:02:55 UTC 2015


On Tue, Nov 3, 2015 at 4: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?).
>

rr should allow a context switch in that case. I'm not sure why you're
deadlocking.

Inserting a sched_yield while busy-waiting should make the problem go away.
Does it?

Does the problem show up if you write a small standalone testcase with the
behavior you described?

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rr-dev/attachments/20151103/92971da5/attachment.html>


More information about the rr-dev mailing list