Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.development.apps > #320

Re: threading question

Show all headers | View raw

Rainer Weikusat wrote, On 12/14/2011 10:33 AM:
> Bill M<wpmccormick@just_about_everywhere.com>  writes:
>> On 12/14/2011 9:48 AM, Rainer Weikusat wrote:
>>> Bill M<wpmccormick@just_about_everywhere.com>   writes:
>>>> If I ctrl-c kill an daemon type application, will child threads
>>>> created by the application also be killed or will they become zombie
>>>> threads?
>>>
>>> There is no such thing as 'a zombie thread', at least not in the sense
>>> you are using the term (technically, a non-detached thread which has
>>> exited will become 'a zombie thread' because the return value will be
>>> kept somewhere until [if ever] another thread calls pthread_join in
>>> order to receive that. While this is similar to 'zombie processes', I
>>> haven't seen the term 'zombie thread' anywhere so far).
>>
>> Right, so if I have a some program ...
>>
>> pthread_create(&thread, ... )
>>
>> while(some_condition)
>> {
>>    ...
>> }
>>
>> pthread_kill(thread, sig);
>> pthread_join(thread, *retval);
>>
>> exit(0);
>>
>> ... and the program is killed, with ctrl-c or some other signal, then
>> the pthread_join is never called. So I *think* I need to trap signals
>> and exit the while loop so I can clean up the thread. Stop me here if
>> I'm not right.
>
> A thread may return a value, either implicitly by returning (return
> statement) from the routine passed to pthread_create or explicitly by
> calling pthread_exit(something). If the thread hasn't been detached,
> this return value will be kept around for perusal by other threads of
> the same process until one of these threads executes a pthread_join
> call asking for it. Neither the thread identifier passed to
> pthread_join nor the return value of the thread (a void *) has any
> meaning outside of the processes which created the
> thread. Consequently, no one would ever be able to query for the
> return value of this thread or make sense of the result after the
> containing process has terminated. This is all 'address space specific
> stuff' which will go away when the kernel destory the address space of
> the deceased process.

Let me ask my question a different way: What is the proper method of 
cleaning up threads before the main routine exits? If your previous 
response answers that question, maybe you could reform your response?

Thanks,

Back to comp.os.linux.development.apps | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

threading question Bill M <wpmccormick@just_about_everywhere.com> - 2011-12-14 09:05 -0600
  Re: threading question Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-12-14 15:48 +0000
    Re: threading question Bill M <wpmccormick@just_about_everywhere.com> - 2011-12-14 10:26 -0600
      Re: threading question Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-12-14 16:33 +0000
        Re: threading question Bill M <wpmccormick@just_about_everywhere.com> - 2011-12-14 11:12 -0600
          Re: threading question Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-12-14 18:10 +0000
            Re: threading question Bill M <wpmccormick@just_about_everywhere.com> - 2011-12-14 13:28 -0600
          Re: threading question Richard Kettlewell <rjk@greenend.org.uk> - 2011-12-14 18:30 +0000
          Re: threading question Mark <i@dontgetlotsofspamanymore.invalid> - 2011-12-15 15:19 +0000
            Re: threading question Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-12-15 15:42 +0000
            Re: threading question Bill M <wpmccormick@just_about_everywhere.com> - 2011-12-15 18:50 -0600
              Re: threading question Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-12-16 03:40 +0000
                Re: threading question Bill M <wpmccormick@just_about_everywhere.com> - 2011-12-16 08:23 -0600

csiph-web