public inbox for pthreads-win32@sourceware.org
 help / color / mirror / Atom feed
* RE: Cancellation points
@ 2002-12-19 15:29 Simon Gerblich
  2002-12-19 16:53 ` Alexander Terekhov
  0 siblings, 1 reply; 9+ messages in thread
From: Simon Gerblich @ 2002-12-19 15:29 UTC (permalink / raw)
  To: pthreads-win32

>BTW,
>
>> pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL)
>                                                 ^^^^
>
>that's incorrect. Don't do this.
>
>regards,
>alexander.

alexander,

Is it correct if I put pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, NULL)
after the small piece of code where I don't want a cancelation point?  I am
aware that if I start using pthread_setcancelstate() in my code I should
take care to use the "oldstate" as described in the RATIONALE and restore
the state correctly.

I was only using pthread_setcancelstate to confirm if there was a problem
with the pthread_mutex_lock() function in the 2002-11-04 snapshot.  

Thanks,
Simon

^ permalink raw reply	[flat|nested] 9+ messages in thread

* RE: Cancellation points
  2002-12-19 15:29 Cancellation points Simon Gerblich
@ 2002-12-19 16:53 ` Alexander Terekhov
  0 siblings, 0 replies; 9+ messages in thread
From: Alexander Terekhov @ 2002-12-19 16:53 UTC (permalink / raw)
  To: pthreads-win32

Simon Gerblich wrote:
[...]
> Is it correct if I put pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, 
NULL)
 ^^^^

> after the small piece of code where I don't want a cancelation point? 

It's correct as long as you use it properly; with proper arguments. 
AFAICS, the use of null pointer for "oldstate"/"oldtype" is incorrect.

http://www.opengroup.org/onlinepubs/007904975/functions/pthread_setcancelstate.html

regards,
alexander.

Sent by:        pthreads-win32-owner@sources.redhat.com
To:     pthreads-win32@sources.redhat.com
cc:      
Subject:        RE: Cancellation points


>BTW,
>
>> pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL)
>                                                 ^^^^
>
>that's incorrect. Don't do this.
>
>regards,
>alexander.

alexander,

Is it correct if I put pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, NULL)
after the small piece of code where I don't want a cancelation point?  I 
am
aware that if I start using pthread_setcancelstate() in my code I should
take care to use the "oldstate" as described in the RATIONALE and restore
the state correctly.

I was only using pthread_setcancelstate to confirm if there was a problem
with the pthread_mutex_lock() function in the 2002-11-04 snapshot. 

Thanks,
Simon


^ permalink raw reply	[flat|nested] 9+ messages in thread

* RE: Cancellation points
@ 2002-12-19  5:00 Alexander Terekhov
  0 siblings, 0 replies; 9+ messages in thread
From: Alexander Terekhov @ 2002-12-19  5:00 UTC (permalink / raw)
  To: pthreads-win32


BTW,

> pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL)
                                                 ^^^^

that's incorrect. Don't do this.

regards,
alexander.



Simon Gerblich <sgerblich@daronmont.com.au>@sources.redhat.com on
12/19/2002 01:28:57 AM

Sent by:    pthreads-win32-owner@sources.redhat.com


To:    pthreads-win32@sources.redhat.com
cc:
Subject:    RE: Cancellation points


Ross,

I've tried the current CVS version and built the VC, VCE and VSE libraries
and they all pass the test suite.
Exception2.exe poped up an exception message for the VC and VSE library and
printed out a message for the VCE library.
My problem with pthread_mutex_lock being a cancelation point is fixed as
well.
I'm using Visual C++ 6.0 SP5 on Windows 2000.

Thanks
Simon

> -----Original Message-----
> From:            Ross Johnson [SMTP:rpj@ise.canberra.edu.au]
> Sent:            Tuesday, December 17, 2002 6:44 PM
> To:        pthreads-win32@sources.redhat.com
> Subject:         Re: Cancellation points
>
> I've changed pthread_mutex_lock() in CVS to use a non-cancelable
> version of sem_wait(). I may not be able to build or test it myself
> for a day or so. Can someone grab the current CVS version, build the
> library, run the test suite, and report success or failure to the
> list please.
>
> Otherwise I'll test it myself ASAP.
>
> Thanks.
> Ross
>
> Ross Johnson wrote:
> > Hi Simon,
> >
> > Sleep() [with uppercase 'S'] is definitely not a cancelation point -
> > only functions included with pthreads-win32 can be cancelation points.
> > The POSIX function sleep() isn't provided by pthreads-win32 either.
> >
> > See the Conformance section of the ANNOUNCE file for all functions that

> > have been implemented. Any of those that should be cancelation points
> are.
> >
> > Re pthread_mutex_lock(), Thomas Pfaff discovered this bug only a few
> > days ago and tracked it down (to an error of mine). I will fix it and
> > drop it into CVS ASAP.
> >
> > Thanks.
> > Ross
> >
> > Simon Gerblich wrote:
> >
> >> Hi,
> >>
> >> I'm having some problems working out which functions are cancellation
> >> points
> >> when using
> >> pthread_cancel() with pthread_setcanceltype(PTHREAD_CANCEL_DEFERRED,
> >> NULL).
> >> I'm using pthreadsVC.dll on Windows 2000.
> >>
> >> Is Sleep() meant to be a cancellation point in WIN32?  I've read in
the
> >> Solaris reference
> >> manual that sleep() and usleep() are cancellation points for pthreads
> on
> >> Solaris, but can
> >> not find a list of cancellation points for pthreads on WIN32.
> >>
> >> Also pthread_mutex_lock() is acting as a cancellation point in my
> >> code.  I
> >> have to put
> >> pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL) before my
> >> calls to pthread_mutex_lock to stop it acting as a cancellation
> >> point.  If
> >> the thread
> >> cancellation occurs in a call to pthread_mutex_lock(), the mutex that
> was
> >> being locked
> >> returns EBUSY when destroyed with pthread_mutex_destroy().  Has anyone

> >> else
> >> seen this happen?
> >> Thanks for any help,
> >> Simon Gerblich


^ permalink raw reply	[flat|nested] 9+ messages in thread

* RE: Cancellation points
@ 2002-12-18 16:29 Simon Gerblich
  0 siblings, 0 replies; 9+ messages in thread
From: Simon Gerblich @ 2002-12-18 16:29 UTC (permalink / raw)
  To: pthreads-win32

Ross,

I've tried the current CVS version and built the VC, VCE and VSE libraries
and they all pass the test suite.
Exception2.exe poped up an exception message for the VC and VSE library and
printed out a message for the VCE library.
My problem with pthread_mutex_lock being a cancelation point is fixed as
well.
I'm using Visual C++ 6.0 SP5 on Windows 2000.

Thanks
Simon

> -----Original Message-----
> From:	Ross Johnson [SMTP:rpj@ise.canberra.edu.au]
> Sent:	Tuesday, December 17, 2002 6:44 PM
> To:	pthreads-win32@sources.redhat.com
> Subject:	Re: Cancellation points
> 
> I've changed pthread_mutex_lock() in CVS to use a non-cancelable 
> version of sem_wait(). I may not be able to build or test it myself 
> for a day or so. Can someone grab the current CVS version, build the 
> library, run the test suite, and report success or failure to the 
> list please.
> 
> Otherwise I'll test it myself ASAP.
> 
> Thanks.
> Ross
> 
> Ross Johnson wrote:
> > Hi Simon,
> > 
> > Sleep() [with uppercase 'S'] is definitely not a cancelation point - 
> > only functions included with pthreads-win32 can be cancelation points. 
> > The POSIX function sleep() isn't provided by pthreads-win32 either.
> > 
> > See the Conformance section of the ANNOUNCE file for all functions that 
> > have been implemented. Any of those that should be cancelation points
> are.
> > 
> > Re pthread_mutex_lock(), Thomas Pfaff discovered this bug only a few 
> > days ago and tracked it down (to an error of mine). I will fix it and 
> > drop it into CVS ASAP.
> > 
> > Thanks.
> > Ross
> > 
> > Simon Gerblich wrote:
> > 
> >> Hi,
> >>
> >> I'm having some problems working out which functions are cancellation 
> >> points
> >> when using
> >> pthread_cancel() with pthread_setcanceltype(PTHREAD_CANCEL_DEFERRED, 
> >> NULL).
> >> I'm using pthreadsVC.dll on Windows 2000.
> >>
> >> Is Sleep() meant to be a cancellation point in WIN32?  I've read in the
> >> Solaris reference
> >> manual that sleep() and usleep() are cancellation points for pthreads
> on
> >> Solaris, but can
> >> not find a list of cancellation points for pthreads on WIN32.
> >>
> >> Also pthread_mutex_lock() is acting as a cancellation point in my 
> >> code.  I
> >> have to put
> >> pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL) before my
> >> calls to pthread_mutex_lock to stop it acting as a cancellation 
> >> point.  If
> >> the thread
> >> cancellation occurs in a call to pthread_mutex_lock(), the mutex that
> was
> >> being locked
> >> returns EBUSY when destroyed with pthread_mutex_destroy().  Has anyone 
> >> else
> >> seen this happen? 
> >> Thanks for any help,
> >> Simon Gerblich
> > 
> > 
> 

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Cancellation points
  2002-12-17  0:15   ` Ross Johnson
@ 2002-12-17  1:09     ` Norman Vine
  0 siblings, 0 replies; 9+ messages in thread
From: Norman Vine @ 2002-12-17  1:09 UTC (permalink / raw)
  To: pthreads-win32

Ross Johnson writes:
>
> I've changed pthread_mutex_lock() in CVS to use a non-cancelable 
> version of sem_wait(). I may not be able to build or test it myself 
> for a day or so. Can someone grab the current CVS version, build the 
> library, run the test suite, and report success or failure to the 
> list please.

<591> tests
$ gcc --version
gcc.exe (GCC) 3.2.1 (MinGW special 20021202-2)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


<592> tests
$ make GC
make GCX=GC XXCFLAGS="-x c -D__CLEANUP_C" all-pass
make[1]: Entering directory `/usr/mingw/src/pthreads/tests'
ALL TESTS PASSED! Congratulations!
make[1]: Leaving directory `/usr/mingw/src/pthreads/tests'

Thanks 

Norman

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Cancellation points
  2002-12-16 23:24 ` Ross Johnson
@ 2002-12-17  0:15   ` Ross Johnson
  2002-12-17  1:09     ` Norman Vine
  0 siblings, 1 reply; 9+ messages in thread
From: Ross Johnson @ 2002-12-17  0:15 UTC (permalink / raw)
  To: pthreads-win32

I've changed pthread_mutex_lock() in CVS to use a non-cancelable 
version of sem_wait(). I may not be able to build or test it myself 
for a day or so. Can someone grab the current CVS version, build the 
library, run the test suite, and report success or failure to the 
list please.

Otherwise I'll test it myself ASAP.

Thanks.
Ross

Ross Johnson wrote:
> Hi Simon,
> 
> Sleep() [with uppercase 'S'] is definitely not a cancelation point - 
> only functions included with pthreads-win32 can be cancelation points. 
> The POSIX function sleep() isn't provided by pthreads-win32 either.
> 
> See the Conformance section of the ANNOUNCE file for all functions that 
> have been implemented. Any of those that should be cancelation points are.
> 
> Re pthread_mutex_lock(), Thomas Pfaff discovered this bug only a few 
> days ago and tracked it down (to an error of mine). I will fix it and 
> drop it into CVS ASAP.
> 
> Thanks.
> Ross
> 
> Simon Gerblich wrote:
> 
>> Hi,
>>
>> I'm having some problems working out which functions are cancellation 
>> points
>> when using
>> pthread_cancel() with pthread_setcanceltype(PTHREAD_CANCEL_DEFERRED, 
>> NULL).
>> I'm using pthreadsVC.dll on Windows 2000.
>>
>> Is Sleep() meant to be a cancellation point in WIN32?  I've read in the
>> Solaris reference
>> manual that sleep() and usleep() are cancellation points for pthreads on
>> Solaris, but can
>> not find a list of cancellation points for pthreads on WIN32.
>>
>> Also pthread_mutex_lock() is acting as a cancellation point in my 
>> code.  I
>> have to put
>> pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL) before my
>> calls to pthread_mutex_lock to stop it acting as a cancellation 
>> point.  If
>> the thread
>> cancellation occurs in a call to pthread_mutex_lock(), the mutex that was
>> being locked
>> returns EBUSY when destroyed with pthread_mutex_destroy().  Has anyone 
>> else
>> seen this happen? 
>> Thanks for any help,
>> Simon Gerblich
> 
> 


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Cancellation points
  2002-12-16 22:56 Simon Gerblich
@ 2002-12-16 23:24 ` Ross Johnson
  2002-12-17  0:15   ` Ross Johnson
  0 siblings, 1 reply; 9+ messages in thread
From: Ross Johnson @ 2002-12-16 23:24 UTC (permalink / raw)
  To: Simon Gerblich; +Cc: pthreads-win32

Hi Simon,

Sleep() [with uppercase 'S'] is definitely not a cancelation point - 
only functions included with pthreads-win32 can be cancelation 
points. The POSIX function sleep() isn't provided by pthreads-win32 
either.

See the Conformance section of the ANNOUNCE file for all functions 
that have been implemented. Any of those that should be cancelation 
points are.

Re pthread_mutex_lock(), Thomas Pfaff discovered this bug only a few 
days ago and tracked it down (to an error of mine). I will fix it 
and drop it into CVS ASAP.

Thanks.
Ross

Simon Gerblich wrote:
> Hi,
> 
> I'm having some problems working out which functions are cancellation points
> when using
> pthread_cancel() with pthread_setcanceltype(PTHREAD_CANCEL_DEFERRED, NULL).
> I'm using pthreadsVC.dll on Windows 2000.
> 
> Is Sleep() meant to be a cancellation point in WIN32?  I've read in the
> Solaris reference
> manual that sleep() and usleep() are cancellation points for pthreads on
> Solaris, but can
> not find a list of cancellation points for pthreads on WIN32.
> 
> Also pthread_mutex_lock() is acting as a cancellation point in my code.  I
> have to put
> pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL) before my
> calls to pthread_mutex_lock to stop it acting as a cancellation point.  If
> the thread
> cancellation occurs in a call to pthread_mutex_lock(), the mutex that was
> being locked
> returns EBUSY when destroyed with pthread_mutex_destroy().  Has anyone else
> seen this happen?  
> 
> Thanks for any help,
> Simon Gerblich


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Cancellation points
@ 2002-12-16 23:00 Simon Gerblich
  0 siblings, 0 replies; 9+ messages in thread
From: Simon Gerblich @ 2002-12-16 23:00 UTC (permalink / raw)
  To: pthreads-win32

Hi,

I'm having some problems working out which functions are cancellation points
when using pthread_cancel() with
pthread_setcanceltype(PTHREAD_CANCEL_DEFERRED, NULL).  I'm using
pthreadsVC.dll on Windows 2000.

Is Sleep() meant to be a cancellation point in WIN32?  I've read in the
Solaris reference manual that sleep() and usleep() are cancellation points
for pthreads on Solaris, but can not find a list of cancellation points for
pthreads on WIN32.

Also pthread_mutex_lock() is acting as a cancellation point in my code.  I
have to put pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL) before my
calls to pthread_mutex_lock to stop it acting as a cancellation point.  If
the thread cancellation occurs in a call to pthread_mutex_lock(), the mutex
that was being locked returns EBUSY when destroyed with
pthread_mutex_destroy().  Has anyone else seen this happen?  

Thanks for any help,
Simon Gerblich

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Cancellation points
@ 2002-12-16 22:56 Simon Gerblich
  2002-12-16 23:24 ` Ross Johnson
  0 siblings, 1 reply; 9+ messages in thread
From: Simon Gerblich @ 2002-12-16 22:56 UTC (permalink / raw)
  To: pthreads-win32

Hi,

I'm having some problems working out which functions are cancellation points
when using
pthread_cancel() with pthread_setcanceltype(PTHREAD_CANCEL_DEFERRED, NULL).
I'm using pthreadsVC.dll on Windows 2000.

Is Sleep() meant to be a cancellation point in WIN32?  I've read in the
Solaris reference
manual that sleep() and usleep() are cancellation points for pthreads on
Solaris, but can
not find a list of cancellation points for pthreads on WIN32.

Also pthread_mutex_lock() is acting as a cancellation point in my code.  I
have to put
pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL) before my
calls to pthread_mutex_lock to stop it acting as a cancellation point.  If
the thread
cancellation occurs in a call to pthread_mutex_lock(), the mutex that was
being locked
returns EBUSY when destroyed with pthread_mutex_destroy().  Has anyone else
seen this happen?  

Thanks for any help,
Simon Gerblich

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2002-12-20  0:53 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-12-19 15:29 Cancellation points Simon Gerblich
2002-12-19 16:53 ` Alexander Terekhov
  -- strict thread matches above, loose matches on Subject: below --
2002-12-19  5:00 Alexander Terekhov
2002-12-18 16:29 Simon Gerblich
2002-12-16 23:00 Simon Gerblich
2002-12-16 22:56 Simon Gerblich
2002-12-16 23:24 ` Ross Johnson
2002-12-17  0:15   ` Ross Johnson
2002-12-17  1:09     ` Norman Vine

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