From owner-freebsd-threads@FreeBSD.ORG Wed Sep 19 19:00:37 2007 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E40FD16A417 for ; Wed, 19 Sep 2007 19:00:37 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 9DE0A13C4D9 for ; Wed, 19 Sep 2007 19:00:37 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.1/8.14.1/NETPLEX) with ESMTP id l8JIa1eS002258; Wed, 19 Sep 2007 14:36:01 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.netplex.net [204.213.176.10]); Wed, 19 Sep 2007 14:36:01 -0400 (EDT) Date: Wed, 19 Sep 2007 14:36:01 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Sean Chittenden In-Reply-To: <22249390-ABCD-4993-977C-02D7AEB0CE69@chittenden.org> Message-ID: References: <22249390-ABCD-4993-977C-02D7AEB0CE69@chittenden.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: threads@freebsd.org Subject: Re: Programatic way to determine the contents of struct pthread_*_t... X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 19:00:38 -0000 On Wed, 19 Sep 2007, Sean Chittenden 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? You can't do that. The pthread_*_t things are opaque and can and will change over time. D or Tango or whatever it is is severely broken. Not even Java or Ada need this kind of access. Now I almost feel like changing the pthread_*_t layouts around every couple of months ;-) -- DE