|
Home > Archive > Unix Programming > August 2005 > pthread_detach after pthread_join
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
pthread_detach after pthread_join
|
|
| John Smith 2005-08-23, 5:56 pm |
| Hello,
I am writing a thread class in c++ which makes use of pthread api under
linux. I've been using this code for a while under both Linux Redhat 9.0 and
Mac OS X 10.3 with no problems. However when I compiled my code under Fedora
core 4 today I ran into a problem.
When I spawn a thread I often end up calling pthread_join to make sure it's
closed again. In destructor of the class I also call pthread_detach which I
assumed was nessecary to reclaim resources for the thread. This makes the
program seg fault though. Removing the pthread_detach code it works fine.
Isn't it nessecary to call pthread_detach after pthread_join? Maybe I should
only call it incase join is never called.
Thanks in advance.
-- John
| |
| Loic Domaigne 2005-08-23, 5:56 pm |
| Hi John,
> When I spawn a thread I often end up calling pthread_join to make sure it's
> closed again. In destructor of the class I also call pthread_detach which I
> assumed was nessecary to reclaim resources for the thread. This makes the
> program seg fault though. Removing the pthread_detach code it works fine.
>
> Isn't it nessecary to call pthread_detach after pthread_join? Maybe I should
> only call it incase join is never called.
A thread is either "joinable" or "detached". The function
pthread_create() creates joinable thread when default thread attribute
are used.
A joinable thread - as its name reveals - can be joined at some point in
another thread using the function pthread_join(). The function
pthread_join() is similar to the function waitpid() at the thread level:
it waits until the thread has terminated its execution. If the thread
has already finished when pthread_join(), then this function returns
immediately.
When a joinable thread has terminated, but has not been yet joined, the
thread id, the returned value and possibly other information are
retained. Until you join the thread.
There are situations where you don't care about return value of the
thread. It just lives and dies, quite independently from the rest of the
world. In that case, you can tell the libpthread to free the resources
attached to the thread as soon as this thread terminates. Such a thread
is called "detached". A possibility to detach a thread is to use the
function pthread_detach().
As you see, pthread_join() and pthread_detach() are quite unrelated. It
makes actually no sense at all to call pthread_detach() after a
pthread_join().
I am quite surprised however that you get a SIGSEGV (assuming that the
thread id isn't located on an invalid stack location). Normally,
pthread_detach() should return ESRCH when the thread id isn't valid.
HTH,
Loic.
| |
| John Smith 2005-08-23, 5:56 pm |
| >
> I am quite surprised however that you get a SIGSEGV (assuming that the
> thread id isn't located on an invalid stack location). Normally,
> pthread_detach() should return ESRCH when the thread id isn't valid.
>
This is also what happened for the first 3 calls to that function. But after
more calls it crashed instead. Since I will clean up my code all together it
won't be a problem anymore though.
Thanks for your explanation.
-- John
| |
| David Schwartz 2005-08-23, 5:56 pm |
|
"John Smith" <john.smith@x-formation.com> wrote in message
news:430b7459$0$22533$edfadb0f@dread16.news.tele.dk...
> I am writing a thread class in c++ which makes use of pthread api under
> linux. I've been using this code for a while under both Linux Redhat 9.0
> and
> Mac OS X 10.3 with no problems. However when I compiled my code under
> Fedora
> core 4 today I ran into a problem.
>
> When I spawn a thread I often end up calling pthread_join to make sure
> it's
> closed again. In destructor of the class I also call pthread_detach which
> I
> assumed was nessecary to reclaim resources for the thread. This makes the
> program seg fault though. Removing the pthread_detach code it works fine.
>
> Isn't it nessecary to call pthread_detach after pthread_join? Maybe I
> should
> only call it incase join is never called.
After you join a thread, it no longer exists. So you are attempting to
detach a non-existent thread.
DS
| |
| David Schwartz 2005-08-23, 5:56 pm |
|
"Loic Domaigne" <loic-dev@gmx.net> wrote in message
news:3n1cl8F18msdnU1@individual.net...
> I am quite surprised however that you get a SIGSEGV (assuming that the
> thread id isn't located on an invalid stack location). Normally,
> pthread_detach() should return ESRCH when the thread id isn't valid.
The thread id isn't guaranteed to be invalid.
DS
| |
| Loic Domaigne 2005-08-23, 5:56 pm |
| >>I am quite surprised however that you get a SIGSEGV (assuming that the
>
>
> The thread id isn't guaranteed to be invalid.
Yes sure. And actually, the thread id will be perfectly valid if a new
thread got created after the pthread_join() but prior to the
pthread_detach(). This is due to the thread id recycling policy used by
NPTL.
But it doesn't explain the SIGSEGV ?
Loic.
| |
| Måns Rullgård 2005-08-23, 5:56 pm |
| Loic Domaigne <loic-dev@gmx.net> writes:
>
> Yes sure. And actually, the thread id will be perfectly valid if a new
> thread got created after the pthread_join() but prior to the
> pthread_detach(). This is due to the thread id recycling policy used
> by NPTL.
>
> But it doesn't explain the SIGSEGV ?
IIRC, NTPL thread IDs are simply pointers. Using an invalid pointer
is quite likely to cause all sorts of mayhem, including SIGSEGV. In
fact, you should consider yourself lucky if a SIGSEGV is all you get.
--
Måns Rullgård
mru@inprovide.com
| |
| David Schwartz 2005-08-23, 9:02 pm |
|
"Loic Domaigne" <loic-dev@gmx.net> wrote in message
news:3n1kepF18cvf3U1@individual.net...
[vbcol=seagreen]
[vbcol=seagreen]
> Yes sure. And actually, the thread id will be perfectly valid if a new
> thread got created after the pthread_join() but prior to the
> pthread_detach(). This is due to the thread id recycling policy used by
> NPTL.
> But it doesn't explain the SIGSEGV ?
The thread ID could be valid, could be invalid, could be in the process
of becoming valid because a thread is in the process of being created. It
could be in any state at all, including one that is totally illegal. This
explains the SIGSEGV -- the thread ID could be valid, invalid, or somewhere
inbetween.
DS
| |
| Loic Domaigne 2005-08-24, 2:49 am |
| Hi Måns,
>
>
> IIRC, NTPL thread IDs are simply pointers. Using an invalid pointer
> is quite likely to cause all sorts of mayhem, including SIGSEGV. In
> fact, you should consider yourself lucky if a SIGSEGV is all you get.
Ah yes, good point here.
I had in mind the old scheme used by LinuxThreads which allows to detect
quite reliability if a thread id isn't used.
Thanks,
Loic.
|
|
|
|
|