public inbox for pthreads-win32@sourceware.org
 help / color / mirror / Atom feed
From: "Robert Kindred" <RKindred@SwRI.edu>
To: "Ross Johnson" <rpj@ise.canberra.edu.au>,
	"pthreads-win32" <pthreads-win32@sources.redhat.com>
Subject: RE: snap-2004-11-03 breakage
Date: Thu, 04 Nov 2004 18:06:00 -0000	[thread overview]
Message-ID: <IIEJIMCOHAKGODCMHFEOGEAECCAA.RKindred@SwRI.edu> (raw)
In-Reply-To: <418904C8.8090706@ise.canberra.edu.au>



> -----Original Message-----
> From: pthreads-win32-owner@sources.redhat.com
> [mailto:pthreads-win32-owner@sources.redhat.com]On Behalf Of Ross
> Johnson
> Sent: Wednesday, November 03, 2004 10:18 AM
> To: pthreads-win32
> Subject: Re: snap-2004-11-03 breakage
>
>
> 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.

Let me take a quick look at my code...    Oops, I typed too soon.  I am not
actually switching on a pthread_t.  I am switching code on a
pthread_mutex_t.  I must create and initialize these differently on the two
platforms.  Perhaps there is a portable way that I don't know about?

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

  parent reply	other threads:[~2004-11-04 18:06 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 [this message]
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=IIEJIMCOHAKGODCMHFEOGEAECCAA.RKindred@SwRI.edu \
    --to=rkindred@swri.edu \
    --cc=pthreads-win32@sources.redhat.com \
    --cc=rpj@ise.canberra.edu.au \
    /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).