|
From: Jeremy F. <je...@go...> - 2005-06-17 05:43:12
|
Ashley Pittman wrote:
>Probably the result on an implicit close(). Very few programs call
>detach or close so it will come from the fd being closed on program
>teardown.
>
>
There won't be an implicit close until the process actually exits
though, so this isn't relevent to the "won't exit under Valgrind" problem.
>>In the 2.4/LinuxThreads case, the threads library coordinates the
>>process termination by getting each thread to explicitly call exit().
>>There are some tricky edge cases depending on whether the manager thread
>>or the initial thread is the last to exit. Again, Valgrind only exits
>>once all threads have terminated.
>>
>>
>
>This isn't going to happen until what I guess you are referring to as
>the initial thread has exited, couldn't deadlock also happen this way?
>How exactly does it do in this coordination?
>
>
Well, the client's initial thread may exit, but Valgrind itself will
keep using that thread to wait for other threads to exit; if the elan
thread is waiting for the initial thread to exit, there's the deadlock.
> if ((res = __clone (elan3_lwp, stack + ELANLWP_STACK_SIZE,
> CLONE_VM | CLONE_FS | CLONE_FILES |
>CLONE_SIGHAND,
> (void *) ctx)) == -1)
>
>
Counter-intuitively, you need to request to be part of the thread group,
with CLONE_THREAD, so this call will create a new thread group.
J
|