[Gc] about gc and pthread_win32

Boehm, Hans hans.boehm at hp.com
Mon May 14 13:04:47 PDT 2007


Good point.  It really should not make that assumption.  The down side
is that there are serious difficulties with not making it, since I need
to be able to hash on it, and I need to be able to generate an invalid
thread id.  Also Linux seems to use a function call for pthread_equal.

Based on a quick web search, it looks to me like the hashing problem is
unavoidable, and this really can't be done portably without inventing a
replacement notion of thread id.  Thus I'm inclined to just invent
platform-dependent macros for (a) thread comparison (usually integer
comparison, but pthread_equal where needed) and (b) mapping pthread_t to
an identifying integer.  (Multiple threads may have the same associated
identifying integer, though that should be rare.)

Does that sound plausible?

This would need to be completed and checked by someone like you with
easy access to a platform that uses a struct as pthread_t.

Hans

> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com 
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Romano Paolo Tenca
> Sent: Saturday, May 12, 2007 4:06 PM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] about gc and pthread_win32
> 
> Can gc 7.0 do not assume that pthread_t is an int value?
> 
> I should like to use pthread_win32 under mingw32 with gc but 
> this is the definition found in pthread_h:
> 
> typedef struct {
>     void * p; 
>     unsigned int x;
> } ptw32_handle_t;
> 
> typedef ptw32_handle_t pthread_t;
> 
> 
> 
> --
> Ciao
> Romano Paolo Tenca
> 
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> 



More information about the Gc mailing list