public inbox for
 help / color / mirror / Atom feed
From: "Panagiotis E. Hadjidoukas" <>
To: <>
Subject: Re: problem using pthread_cancel and pthread_mutex_lock
Date: Tue, 09 Mar 2004 15:09:00 -0000	[thread overview]
Message-ID: <003801c405e0$32c91a70$6b64fe83@lesvos> (raw)
In-Reply-To: <>

In general, don' t you agree that an "official" extension of QueueUserAPC
(e.g. QueueUserAPCEx, that automatically sets the target thread in alertable
would be very useful?


----- Original Message ----- 
From: "Brano Kemen" <>
To: <>
Sent: Tuesday, March 09, 2004 4:15 PM
Subject: Re: problem using pthread_cancel and pthread_mutex_lock

> Ross Johnson wrote:
> > There is another reason to avoid async cancelation that is specific to
> > pthreads-win32: this implementation only approximates async cancelation
> > because it relies on the thread actually running at some point after
> > cancelation. So if your thread is blocked on a resource at the time that
> > it's async canceled, it won't actually exit until it's unblocked in some
> > way to resume execution (at which point it will exit immediately) - and
> > if you can do that then you don't need async cancelation anyway.
> > Unfortunately, the time you're most likely to really need an async
> > cancel - to kill a thread blocked on a system resource that you can't
> > unblock - is the very time it won't work in pthreads-win32, and if it
> > did work, as in does in other implementations, then you'd probably be
> > creating a resource leak. So it's hard to find a good argument for async
> > cancel.
> There's one thing that can help with the blocked threads in windows. It's
the undocumented "NtAlertThread" function that is exported from ntdll.dll,
that apparently wakes up the thread even when blocked (listening on socket
etc.), so it would run the injected cancelation code.
> We use async cancelation in our project (
without problems.
> On a related note - I think there's bug in pthread_cancel.c in the 'else'
block starting at line 146. Thread is suspended, and then checked with
WaitForSingleObject(threadH, 0)  if it did not exit already. But if it did,
the thread->cancelLock (locked at line 129) is never unlocked back.
> brk

  reply	other threads:[~2004-03-09 15:09 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-23 17:43 vc
2004-03-01 16:27 ` vc
2004-03-04 23:13   ` Ross Johnson
2004-03-09 14:06     ` vc
2004-03-09 14:15     ` Brano Kemen
2004-03-09 15:09       ` Panagiotis E. Hadjidoukas [this message]
2004-03-09 15:42         ` Brano Kemen
2004-02-24  4:23 Simon Gerblich
2004-02-26 15:59 ` vc
2004-03-09 23:25 Simon Gerblich
2004-03-10  0:57 ` Will Bryant
2004-03-10 11:11 ` vc

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:

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

  git send-email \
    --in-reply-to='003801c405e0$32c91a70$6b64fe83@lesvos' \ \ \

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