public inbox for
 help / color / mirror / Atom feed
From: "Virgilio Alexandre Fornazin" <>
To: "'Ross Johnson'" <>,
		"'Torsten Andre2'" <>
Cc: <>
Subject: RE: Pthread_join waits endlessly for already ended thread
Date: Thu, 19 Mar 2009 11:54:00 -0000	[thread overview]
Message-ID: <00c801c9a889$66077340$321659c0$> (raw)
In-Reply-To: <>

I had a problem similar to this, and creating an event handle for signaling
solves nothing.

I had this problem in plain win32 threads before. This always happened in
It´s probably a bad design / limitation in win32 shared library model. The
cause, if I remember, 
is that the heap is locked in  some way that functions related to thread
(TerminateThread if I'm 
not missing other) must access this heap, then it deadlocks in some locking
Windows have internally.

Install debug symbols for your platform. When the thread get 'stuck', do a
break all and get the
backtrace for blocking thread (probably the thread calling pthread_join).
Then you can see what 
is happening.

Hope to help fix this



-----Original Message-----
[] On Behalf Of Ross Johnson
Sent: quarta-feira, 18 de março de 2009 21:34
To: Torsten Andre2
Subject: Re: Pthread_join waits endlessly for already ended thread

I'm looking for possible bugs in the library that might explain this. 
For example, pthread_join() relies on the underlying Win32 thread handle 
close being signalled and I don't think this is occurring in all cases. 
Replacing this with a dedicated event may be a better way to go.

Re cleanup styles in general, just make sure your code and the pthreads 
library are built using the same cleanup style. If you run against the 
pthreadVCE2.dll then you must build your code with __CLEANUP_CXX 
defined. If no style is defined then __CLEANUP_C is used by default 
(assuming pthreadVC2.dll). But AFAICS this shouldn't cause the longjmp() 
hang issue which is internal to the library. Unless you have a specific 
need, use pthreadVC2.dll.

Also, if you're using the VS project file from the library source code 
please check it carefully because it's not really maintained. The 
pre-built dlls are all built using command line tools and the makefiles 


Torsten Andre2 wrote:
> Hello,
> I'm having trouble concerning pthread_join as described in this [1]
> posting. A "thread A" endlessly waits for an already ended "thread B"
> called "return NULL" or "pthread_exit(NULL)" (tried both). Sometimes it
> seems if you wait long enough thread A passes the pthread_join statement,
> though not always. Unfortunately I haven't been able to find anything in
> the mail archive, though I am sure that this has been covered before.
> Thread B hangs while calling longjmp (sp->start_mark, exception) in
> ptw32_throw.c. I have read about the different styles to cleanup, but I
> have to admit that currently I don't understand what they are about. All
> that matters is that I get pthreads to execute properly at the moment.
> I downloaded pthreads 2.8.0 source code and use Visual Studio 2008
> Professional C++  to compile it using Win32-Debug settings on a Windows
> Server 2008 x64 system. I haven't changed any settings of the VC++
> project . The program calling pthread functions is written in C++. Besides
> using the source code without any alterations, I also tried to use the
> binary dll versions VC2 and VCE2. Both dll's did not solve the problem.
> In [1] Ross states the problem may be another dllmain being called. Though
> I don't believe that's the problem in my case, I don't define any other
> dllmains but the one in Pthreads. Most probably, I guess, the problem is a
> wrong defined symbol or something related.
> Can someone please give me a hint how to get pthread to work properly? Any
> help is highly appreciated. Thank you.
> Cheers,
>       Torsten
> [1]

Faça ligações para outros computadores com o novo Yahoo! Messenger

  reply	other threads:[~2009-03-19 11:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-16 13:14 Torsten Andre2
2009-03-19  0:34 ` Ross Johnson
2009-03-19 11:54   ` Virgilio Alexandre Fornazin [this message]
2009-03-20 23:37     ` Ross Johnson
2009-03-22 21:51       ` good job! Michel Pacilli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='00c801c9a889$66077340$321659c0$' \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).