public inbox for pthreads-win32@sourceware.org
 help / color / mirror / Atom feed
From: "Bossom, John" <John.Bossom@Cognos.COM>
To: 'Ollie Leahy' <ollie@mpt.ie>, pthreads-win32@sources.redhat.com
Subject: RE: Problem in pthread_cancel() ?
Date: Wed, 06 Sep 2000 08:21:00 -0000	[thread overview]
Message-ID: <430F887D415DD1118C2700805F31ECF1037F1320@sota0005.cognos.com> (raw)

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

             reply	other threads:[~2000-09-06  8:21 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-09-06  8:21 Bossom, John [this message]
2000-09-06 17:38 ` Ross Johnson
  -- strict thread matches above, loose matches on Subject: below --
2000-09-06  1:32 Ollie Leahy

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=430F887D415DD1118C2700805F31ECF1037F1320@sota0005.cognos.com \
    --to=john.bossom@cognos.com \
    --cc=ollie@mpt.ie \
    --cc=pthreads-win32@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

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