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
> >
> >
> >
> >
>
>
next prev 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).