public inbox for pthreads-win32@sourceware.org
 help / color / mirror / Atom feed
From: "Alexander Terekhov" <TEREKHOV@de.ibm.com>
To: pthreads-win32@sources.redhat.com
Subject: RE: Cancellation points
Date: Thu, 19 Dec 2002 05:00:00 -0000	[thread overview]
Message-ID: <OF5E52C824.F29FD01D-ONC1256C94.0047310F-C1256C94.0047822B@de.ibm.com> (raw)


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


             reply	other threads:[~2002-12-19 13:00 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-19  5:00 Alexander Terekhov [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-12-19 15:29 Simon Gerblich
2002-12-19 16:53 ` 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

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=OF5E52C824.F29FD01D-ONC1256C94.0047310F-C1256C94.0047822B@de.ibm.com \
    --to=terekhov@de.ibm.com \
    --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).