public inbox for pthreads-win32@sourceware.org
 help / color / mirror / Atom feed
From: Ross Johnson <rpj@ise.canberra.edu.au>
To: Erik Hensema <erik.hensema@group2000.nl>
Cc: "'Pthreads-win32'" <pthreads-win32@sourceware.cygnus.com>
Subject: Re: cancelation problem
Date: Tue, 09 Nov 1999 17:20:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.05.9911092302470.4261-100000@swan.canberra.edu.au> (raw)
In-Reply-To: <A01E735D4940D311A3850090275559330BA998@NTSRV02>

On Mon, 8 Nov 1999, Erik Hensema wrote:

> Hi,
> 
> I'm investigating a problem regarding thread cancelation. The thread I want
> to cancel has PTHREAD_CANCEL_ASYNCHRONOUS, however, this piece of code
> blocks on the join():
> 
> 		if ((retv = Pthread_cancel( recvThread )) == 0)
> 		{
> 			retv = Pthread_join( recvThread, 0 );
> 		}
> 
> Pthread_* are just macro's; they call pthread_*. 
> 
> The thread recvThread seems to block on a select() call. It doesn't get
> cancelled.
> 
> Two questions:
> 
> 1) is this normal behaviour? 
> 
> 2) if not, how does the cancel mechanism work? I'm not very familliar to
> win32 programming, so I don't really understand how the *Event() family of
> calls work.
> 

Hi Erik,

The answer to your first question is, normal POSIX behaviour would
be to asynchronously cancel the thread.

However ...

Pthreads-win32 doesn't support asynchronous cancelation, only
deferred, which is also very limited. The reason there is no async
cancelation is that it's very hard, if not impossible, to implement
on top of Win32.

Incidently, Butenhof "Programming with POSIX Threads"  recommends
not using async cancelation because the possible side effects are
unpredictable, especially if you're trying to write portable code.

Using deferred cancelation would normally be the way to go, however,
even though the POSIX threads standard lists a number of C library
functions that are defined as deferred cancelation points, there is
no hookup between those which are provided by Windows and the
pthreads-win32 library.

Incidently, it's worth noting for code portability that the POSIX
threads standard list doesn't include "select" because (as I read in
Butenhof) it isn't recognised by POSIX.

Effectively, the only cancelation points that pthreads-win32 can
recognise are those the library implements itself, ie.

	pthread_testcancel
	pthread_cond_wait
	pthread_cond_timedwait
	sem_wait

Hmmm, pthread_join should also be a cancelation point, but I see
that it isn't yet. That should be easy to fix.

Pthreads-win32 also provides two functions that allow you to create
cancelation points within your application, but only for cases where
a thread is going to block on a Win32 handle. These are:

	pthreadCancelableWait(HANDLE waitHandle) /* Infinite wait */

	pthreadCancelableTimedWait(HANDLE waitHandle, DWORD timeout)

Regards.
Ross

+----------------------+---+
| Ross Johnson         |   | E-Mail: rpj@ise.canberra.edu.au
| Info Sciences and Eng|___|
| University of Canberra   | FAX:    +61 6 2015227
| PO Box 1                 |
| Belconnen  ACT    2616   | WWW:    http://willow.canberra.edu.au/~rpj/
| AUSTRALIA                |
+--------------------------+



  reply	other threads:[~1999-11-09 17:20 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-11-08  2:20 Erik Hensema
1999-11-09 17:20 ` Ross Johnson [this message]
1999-11-09 23:41 Erik Hensema

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=Pine.LNX.4.05.9911092302470.4261-100000@swan.canberra.edu.au \
    --to=rpj@ise.canberra.edu.au \
    --cc=erik.hensema@group2000.nl \
    --cc=pthreads-win32@sourceware.cygnus.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).