From: Ross Johnson <rpj@callisto.canberra.edu.au>
To: pthreads-win32@sources.redhat.com
Subject: Reuse of Thread IDs
Date: Thu, 14 Aug 2003 10:38:00 -0000 [thread overview]
Message-ID: <3F3B6678.7060401@callisto.canberra.edu.au> (raw)
Hi all,
Nicolas Barry has discovered that a couple of routines
(pthread_getschedparam etc) had rather iffy thread validation checks
that could ultimately segfault due to pthread_t being a simple pointer
to alloced memory that was being freed on thread exit. This weakness in
the library hasn't been entirely unanticipated though, but it's time has
arrived.
These routines also returned an incorrect error value (EINVAL instead or
ESRCH).
As a result, I've changed the way that threads are managed slightly.
The validation check is now stronger and goes as far as checking the
validity of the underlying Win32 thread HANDLE stored in the POSIX
thread handle. To make work, the library (as of the current CVS version)
now no longer frees pthread structs when a thread exits. Instead it
pushes disused structs onto a LIFO stack (implemented as a simple
guarded linked list). Thread handles are still calloced if no disused
handles are available.
There is now also an exported pthread_kill() routine, but it only
accepts a zero value for the signal arg. Any other value will return
EINVAL. It's intended to be used by applications that want to test the
validity of a POSIX thread handle (as intended by the standard).
I've added a few more tests to the test suite, and the library passes
all of the tests so hopefully these changes will be pretty transparent
to your applications. I hope to get a new snapshot out soon, with
pre-built DLLs and libs as usual.
I've also made changes that fix a number of problems that came up when I
changed to using the current MinGW + MsysDTK environment.
Regards.
Ross
reply other threads:[~2003-08-14 10:38 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=3F3B6678.7060401@callisto.canberra.edu.au \
--to=rpj@callisto.canberra.edu.au \
--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).