public inbox for
 help / color / mirror / Atom feed
From: "Bossom, John" <John.Bossom@Cognos.COM>
To: "Ross Johnson" <>,
	"pthreads-win32" <>
Subject: RE: snap-2004-11-03 breakage
Date: Wed, 03 Nov 2004 16:15:00 -0000	[thread overview]
Message-ID: <> (raw)

I will awaken from my stealth lurking
(Yes Ross, I'm still here!)

The whole goal of the pthreads-win32 initiative is to provide
an implemenation of the POSIX Threads library that is true to
the standard in order to permit code portability from UNIX (& (UNIX-like i.e linux) to Win32.

Thus, any deviation from the standard will render code leveraging
these features non-portable, especially if they are making any assumptions as to the implementation
of this library.

There are implementations of PThreads on unix that use scalar values for ID's,
there are also implementations that use non-scalar ids...

Cheers, (and back to lurking...)

John E. Bossom

P.S. The original implementation of pthreads-win32 made all ID's completely opaque pointers in
order to ensure that a product that leverages the DLL doesn't have to be re-built in order to
pick up a bug fix (i.e. just drop in the fixed DLL).

-----Original Message-----
[]On Behalf Of Ross
Sent: Wednesday, November 03, 2004 9:33 AM
To: pthreads-win32
Subject: Re: snap-2004-11-03 breakage


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:


    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.


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
       This message may contain privileged and/or confidential information.  If you have received this e-mail in error or are not the intended recipient, you may not use, copy, disseminate or distribute it; do not open any attachments, delete it immediately from your system and notify the sender promptly by e-mail that you have done so.  Thank you. 

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

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-03 16:15 Bossom, John [this message]
  -- strict thread matches above, loose matches on Subject: below --
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
     [not found] ` <>
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

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 \ \ \ \ \

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