|
From: Tom H. <to...@co...> - 2006-07-06 14:48:34
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> So: the moral is: if doing a syscall which may cause _some other_
> thread to die, I must retain the lock to avoid such a deadlock.
> OTOH, if doing a syscall which may cause _me_ to die, I must release
> the lock so that others may pick it up in that case.
But all syscalls may cause you to die it you allow for being kill -9'd
in the middle of one... I guess that is only likely for a blocking
call?
> So what do we do for a syscall which causes some arbitrarily (kernel-)
> chosen thread in the process to die? Do any such syscalls exist?
That would be an evil system call.
> All very ugly. Our locking strategy imposes the non-obvious
> requirement of knowing how each syscall affects the liveness of
> each thread in the process.
I don't believe any threaded program is robust in the fact of hard
killing of threads in this way - even without valgrind you would be
hosed if the thread that was killed held a lock at the time.
Interesting, on linux at least there is a possible solution - if we
were using futexes in stead of the pipe (there was such an
implementation at one point) then we could use the new robust
futexes stuff to make sure the lock is released if it was held
by a thread that died.
I'm not sure if that is safe though? Is their any guarantee that the
valgrind internal data structure are safe to handle in such a
circumstance?
Catching SIGCHLD would potentially allow us to do something similar
but would face similar problems about data structure state.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|