* RE: Problem in pthread_cancel() ?
@ 2000-09-06 8:21 Bossom, John
2000-09-06 17:38 ` Ross Johnson
0 siblings, 1 reply; 3+ messages in thread
From: Bossom, John @ 2000-09-06 8:21 UTC (permalink / raw)
To: 'Ollie Leahy', pthreads-win32
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Problem in pthread_cancel() ?
2000-09-06 8:21 Problem in pthread_cancel() ? Bossom, John
@ 2000-09-06 17:38 ` Ross Johnson
0 siblings, 0 replies; 3+ messages in thread
From: Ross Johnson @ 2000-09-06 17:38 UTC (permalink / raw)
To: Bossom, John; +Cc: 'Ollie Leahy', pthreads-win32
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Problem in pthread_cancel() ?
@ 2000-09-06 1:32 Ollie Leahy
0 siblings, 0 replies; 3+ messages in thread
From: Ollie Leahy @ 2000-09-06 1:32 UTC (permalink / raw)
To: pthreads-win32
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2000-09-06 17:38 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-09-06 8:21 Problem in pthread_cancel() ? Bossom, John
2000-09-06 17:38 ` Ross Johnson
-- strict thread matches above, loose matches on Subject: below --
2000-09-06 1:32 Ollie Leahy
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).