On 2011-02-20 10:17, Mathieu Desnoyers wrote: > * Mathieu Desnoyers ([email protected]) wrote: > >> * Yannick Brosseau ([email protected]) wrote: >> >>> Sometimes, the thread in the read function would lock the pipe so the >>> setlinebuf would freeze on it. Set the linebuf before we create the >>> thread to fix this deadlock >>> >> Can you update the description to show which locks are involved in this >> deadlock scenario ? E.g. >> >> - CPU A - CPU B >> >> function function >> lock A (taken) lock B (taken) >> lock B (waiting) >> lock A (waiting) <-- deadlock >> >> Or show it with the lock chain dependency analysis. But it's important >> to have this information along with this kind of fix. >> > Hrm, ok I looked at tap.c, and it's not a deadlock at all: it's rather > that the _tap_comment_stdout thread can start using pipe_r_file when it > is still uninitialized. > > I found a lock in the calls to fgets and setlinebuf, deep in the glibc. If what you says is true, the fix I've proposed is not right. Its the pthread_create that should be moved.
_______________________________________________ ltt-dev mailing list [email protected] http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
