RE: Problem in pthread_cancel() ?

RE: Problem in pthread_cancel() ?

[Bossom, John]

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:ollie@mpt.ie ]
Sent: Wednesday, September 06, 2000 4:33 AM
To: pthreads-win32@sources.redhat.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
	crashes. 

	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 
	implementation.

	Regards,
	Ollie

Re: Problem in pthread_cancel() ?

[Ross Johnson]

I fixed this last night and should have another snapshot
uploaded within 12-24 hours after I check for other suspect
code.

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.)

Ross

"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:ollie@mpt.ie ]
> Sent: Wednesday, September 06, 2000 4:33 AM
> To: pthreads-win32@sources.redhat.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
>         crashes.
> 
>         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
>         implementation.
> 
>         Regards,
>         Ollie

Problem in pthread_cancel() ?

[Ollie Leahy]

	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
	crashes. 

	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 
	implementation.

	Regards,
	Ollie