This is the mail archive of the
mailing list for the pthreas-win32 project.
Re: Problem in pthread_cancel() ?
- To: "Bossom, John" <John dot Bossom at Cognos dot COM>
- Subject: Re: Problem in pthread_cancel() ?
- From: Ross Johnson <rpj at ise dot canberra dot edu dot au>
- Date: Thu, 07 Sep 2000 11:37:31 +1100
- CC: "'Ollie Leahy'" <ollie at mpt dot ie>, pthreads-win32 at sources dot redhat dot com
- Organization: University of Canberra, DMT, xISE
- References: <430F887D415DD1118C2700805F31ECF1037F1320@sota0005.cognos.com>
- Reply-To: rpj at ise dot canberra dot edu dot au
I fixed this last night and should have another snapshot
uploaded within 12-24 hours after I check for other suspect
John is totally correct. I added the retrieve of "self" from TLS
to pthread_cancel() when I added a cancel lock to the pthread
struct. The addition of async cancelation to the library required
pthread_cancel() and other cancelation routines to be cancel-safe.
I must have assumed that pthread_cancel wouldn't be called from
a non-posix thread. That must be the first rule of programming:
never hardcode an assumption when the software can check it.
It has been passing the testsuite because
all of the cancelation tests explicitly retrieve "self" at the
start of their main routines. From now on I'll be doing only
what is minimally required in each test and nothing more :o\
(That would be the first rule of testing.)
"Bossom, John" wrote:
> I believe the original implementation would create an instance
> of a pthread struct for you... (and it should) thus allowing
> you to use pthread calls against your current "thread" of execution
> such as the main process (note: the "process" is simply the
> initial thread). This would eliminate the need to create
> an explicit pthread in order to do these kind of pthread calls
> The mechanism I would recommend is "pthread_self" should boot-strap
> an instance of the pthread struct to the current thread of execution
> if you are not within a thread explicitly created with pthread_create.
> I don't know how the current implementation is getting "self" (I assume
> it is from thread-specific memory) however, I recommend that "self"
> be retrieved using pthread_self(). My original implementation DID
> bind an instance of the pthread struct the calling thread if not
> explicitly created with pthread
> -----Original Message-----
> From: Ollie Leahy [mailto:firstname.lastname@example.org]
> Sent: Wednesday, September 06, 2000 4:33 AM
> To: email@example.com
> Subject: Problem in pthread_cancel() ?
> I don't know whether I am mis-using pthreads or if
> there is a problem in the pthreads-win32 implementation.
> When my process is closing down I want all pthreads
> to complete before I finally return from the process.
> To do this I send a pthread_cancel() to those threads
> that are blocking (on an accept() or a recv() call)
> on Linux this works but with pthread-win32 if I call
> pthread_cancel() from the main process the process
> core dumps. If I create a thread and call cancel()
> from the thread then everything works fine.
> I had a quick look at the code for pthread_cancel() and
> the problem seems to be that pthread_cancel() tests
> whether it is being called to cancel the calling thread
> and references the variable 'self'. But since I call the
> function from the process and not from a thread self
> is NULL, so as soon as self is dereferenced the process
> I have fixed my problem by creating a thread to call
> cancel, and I've also hacked the pthread-win32 code
> so that if self is NULL pthread_cancel() does not
> try to defreference it. I would like to know whether
> I'm trying to do something illegal as far as pthreads
> are concerned or whether there is a bug in the win32