RE: snap-2004-11-03 breakage

["Robert Kindred" <RKindred at SwRI dot edu>]

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