Date: Thu, 27 Jan 2005 19:47:01 -0500 (EST) From: Daniel Eischen <deischen@freebsd.org> To: Medi Montaseri <mmontaseri@amcc.com> Cc: freebsd-threads@freebsd.org Subject: Re: pthread_t in 5.3 Message-ID: <Pine.GSO.4.43.0501271941170.8643-100000@sea.ntplx.net> In-Reply-To: <41F987B7.7080308@amcc.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 27 Jan 2005, Medi Montaseri wrote: > Daniel Eischen wrote: > > >Sorry, what pthread_t is, is not for you to know. It is up to the > >implementation to define it anyway that it wants. And is also why > >there is a pthread_equal() function. > > > >>I'm not interested in the pointer, I'm interested in the numerical > >>thread ID... > > > >There is no such thing as defined by POSIX. > > > >>Now at this point, you'll think all you have to do is to de-reference > >>the pointer. > >>But since 'struct pthrad' is opaque, gdb and myself are clueless to > >>proceed from here. > >>Can someone shed some light on this please... > >> > >> > > > >I think you are trying to do something that is non-standard/portable. > > But on linux, a thread_t is > typedef unsigned long int pthread_t; > I guess the idea was if a file descriptor is a int and a socket is an > int and a process id is an int > then a thread also be an int and people can have an array of those IDs. It doesn't matter what Linux does; it matters what the POSIX standard says. Nothing precludes pthread_t from being an int or long, but you shouldn't rely on it being that way. Even though our pthread_t is an opaque id (pointer), nothing is stopping you from storing them in an array. An array of: pthread_t tids[NUM_THREADS]; works regardless of the whether you are on Linux or FreeBSD. -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.43.0501271941170.8643-100000>