Date: Wed, 19 Sep 2007 09:24:59 -0700 From: Alfred Perlstein <alfred@freebsd.org> To: Sean Chittenden <sean@chittenden.org> Cc: threads@freebsd.org Subject: Re: Programatic way to determine the contents of struct pthread_*_t... Message-ID: <20070919162459.GD79417@elvis.mu.org> In-Reply-To: <22249390-ABCD-4993-977C-02D7AEB0CE69@chittenden.org> References: <22249390-ABCD-4993-977C-02D7AEB0CE69@chittenden.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* Sean Chittenden <sean@chittenden.org> [070919 09:12] wrote: > Howdy. What's the best way to programatically gain access to the > contents of the various struct pthread_*_t members? In OS-X and > Linux, the contents are defined in /usr/include/*/_*pthreads.h, but > that doesn't appear to be the case for FreeBSD at the moment. I'm in > the process of porting D's Tango runtime to FreeBSD[1] and it appears > that due to FreeBSD's multi-thread model, this is a bit problematic. > Is there an obvious (or not so obvious) magic woobie stick that I can > shake at this problem? I'm mostly done with the port at this point, > but am a bit perplexed as to how to approach the poking at internals > problem since D's runtime environment is possibly tied to my kernel > configuration. Less than keen on that reality. Can I safely assume > that libthr is now king of the hill and isn't about to be dethroned > anytime soon? Sean, one thing you might look at is providing an _np() api set for accessing the required data. If this is non-workable, what I suggest doing for the time being is adding some kind of version retrieval function for the thhreading libraries and then just duplicate the struts, at least for the time being. Can you describe what sort of internal access this program you're working on requires? -Alfred
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070919162459.GD79417>