RE: cancelation problem

RE: cancelation problem

[Erik Hensema]

> -----Original Message-----
> From: Ross Johnson [ mailto:rpj@ise.canberra.edu.au ]

> The thread I want
> > to cancel has PTHREAD_CANCEL_ASYNCHRONOUS, however, this 
> piece of code
> > blocks on the join():
[...]
> > The thread recvThread seems to block on a select() call. It 
> doesn't get
> > cancelled.
>
[...]
> 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.

Ok, thank you for your explaination. I have solved the problem by adding a
timeout to the select() call, and looping it infinitely. The thread
cancelation now works as it should.

> 

Re: cancelation problem

[Ross Johnson]

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                |
+--------------------------+

cancelation problem

[Erik Hensema]

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.

-- 
Erik Hensema
Work: erik.hensema@group2000.nl
Home: erik@hensema.xs4all.nl