From: Ross Johnson <rpj@ise.canberra.edu.au>
To: pthreads-win32 <pthreads-win32@sources.redhat.com>
Subject: Re: snap-2004-11-03 breakage
Date: Wed, 03 Nov 2004 16:18:00 -0000 [thread overview]
Message-ID: <418904C8.8090706@ise.canberra.edu.au> (raw)
In-Reply-To: <IIEJIMCOHAKGODCMHFEOMEADCCAA.RKindred@SwRI.edu>
Robert Kindred wrote:
>On the other hand, having pthread_t to be a pointer forces me to put
>compiler switches in my code that runs on both Windows and QNX. I would
>appreciate knowing the general direction things are taking.
>
>
>
What specifics of pthread_t are causing you to have to treat
it differently on different systems? Applications shouldn't
have to know how pthread_t is actually defined.
Re the general direction for the library:
The library has reached a point where it's stable, except
for some relatively quiet issues, such as thread ID reuse,
left to fix. Defining pthread_t as a pointer meant that a
new thread could acquire the same ID as a recently detached
or joined thread, which could be disasterous. There were no
serious bug fixes to the last snapshot and no significant
fundamentally new features added.
The changes to mutexes in this snapshot are also helping
prepare the way for [possibly] making headway on
POSIX_PROCESS_SHARED mutexes, semaphores etc. This may still
prove difficult, but some more definite impedements
have now been removed.
This is the first time in over 6 years, if I recall
correctly, that the library's ABI has changed, and there are
no further changes planned.
Regards.
Ross
>Robert Kindred
>
>-----Original Message-----
>From: pthreads-win32-owner@sources.redhat.com
>[mailto:pthreads-win32-owner@sources.redhat.com]On Behalf Of Gisle Vanem
>Sent: Wednesday, November 03, 2004 7:18 AM
>To: pthreads-win32
>Subject: snap-2004-11-03 breakage
>
>
>snap-2004-11-03 breaks a lot of applications by the way 'pthread_t' is
>defined:
>
>typedef struct {
> void * p; /* Pointer to actual object */
> unsigned int x; /* Extra information - reuse count etc */
>} ptw32_handle_t;
>
>typedef ptw32_handle_t pthread_t;
>
>Code like (from Ettercap)
> pthread_t pid = ec_thread_getpid("golem");
> if (pid != 0)
> ec_thread_destroy(pid);
>
>no longer works; you cannot compare a struct against 0.
>
>I'm not sure you really meant to do that or if the typedef should be
>typedef ptw32_handle_t *pthread_t;
>
>--gv
>
>
>
>
next prev parent reply other threads:[~2004-11-03 16:18 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-03 13:18 Gisle Vanem
2004-11-03 14:28 ` Robert Kindred
2004-11-03 16:18 ` Ross Johnson [this message]
2004-11-03 16:30 ` Peter Slacik
2004-11-04 18:06 ` Robert Kindred
2004-11-03 14:33 ` Ross Johnson
[not found] ` <4188EB13.8000100@ise.canberra.edu.au>
2004-11-03 15:02 ` Gisle Vanem
2004-11-03 15:38 ` Ross Johnson
2004-11-03 15:32 ` Alexander Terekhov
2004-11-03 16:19 ` Ross Johnson
2004-11-03 16:32 ` Alexander Terekhov
2004-11-03 16:15 Bossom, John
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=418904C8.8090706@ise.canberra.edu.au \
--to=rpj@ise.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).