* Yannick Brosseau ([email protected]) wrote: > 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. >
I don't understand. It should only be the relative order of init vs pthread_create (the user of this structure) that matters, no ? Mathieu -- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com _______________________________________________ ltt-dev mailing list [email protected] http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
