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 14:33:00 -0000 [thread overview]
Message-ID: <4188EC35.9080108@ise.canberra.edu.au> (raw)
In-Reply-To: <0b0b01c4c1a7$8a2fe3b0$0600000a@broadpark.no>
Hi,
I definitely don't want to break applications unnecessarily and
particularly applications that have been ported to several different
POSIX systems, but on the other hand POSIX thread IDs are not required
to be scalar. See the rationale from the definition of pthread_equal()
in the Single Unix Specification version 3, which says:
RATIONALE
Implementations may choose to define a thread ID as a structure.
This allows additional flexibility and robustness over using an
*int*. For example, a thread ID could include a sequence number that
allows detection of "dangling IDs" (copies of a thread ID that has
been detached). Since the C language does not support comparison on
structure types, the /pthread_equal/() function is provided to
compare thread IDs.
I don't think this is new to SUS or SUS version 3 either.
Nor (given the above) does the value 0 (zero) for a thread ID have any
special meaning in the standard, although it obviously does as the value
returned by ec_thread_getpid() in ettercap. If you want to test if a
thread exists given it's thread ID, use:
if (pthread_kill(pid, 0) == 0) /* or (... != ESRCH) */
That should be portable to all POSIX implementations.
I'm not dismissing your problem, but in this case I think it would be
better to fix the application.
Regards.
Ross
Gisle Vanem wrote:
> 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 14:33 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
2004-11-03 16:30 ` Peter Slacik
2004-11-04 18:06 ` Robert Kindred
2004-11-03 14:33 ` Ross Johnson [this message]
[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=4188EC35.9080108@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).