This is the mail archive of the pthreads-win32@sources.redhat.com mailing list for the pthreas-win32 project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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.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.
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |