From owner-freebsd-threads@FreeBSD.ORG Thu Jun 19 20:02:08 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A79D537B401 for ; Thu, 19 Jun 2003 20:02:08 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B76643F85 for ; Thu, 19 Jun 2003 20:02:08 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h5K31vXh012393; Thu, 19 Jun 2003 23:01:57 -0400 (EDT) Date: Thu, 19 Jun 2003 23:01:57 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Mike Makonnen In-Reply-To: <20030620023348.PAID20810.pop015.verizon.net@kokeb.ambesa.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Andriy Gapon cc: threads@freebsd.org Subject: Re: Removal of bogus gethostbyaddr_r() X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2003 03:02:09 -0000 On Thu, 19 Jun 2003, Mike Makonnen wrote: > On Thu, 19 Jun 2003 21:40:26 -0400 > Andriy Gapon wrote: > > > > > Btw, what happened to the patch(es) proposed by Maxim Sobolev: > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=13028+0+archive/2002/freebsd-audit/20020818.freebsd-audit > > > > and in Problem Report bin/29581: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/29581 > > > > the discussion in the mailing lists seems to have resulted in nothing, and the > > problem seemed to be of non-unsolvable kind. > > I am not so sure that using pthreads thread local storage is such a good idea > for a couple of reasons: I haven't grep'd, but I'm pretty sure we use pthread keys in a couple of other places in libc. But regardless, ... > 1. There is a finite amount of keys that an application can have open at any > one time (PTHREAD_KEYS_MAX). On FreeBSD this is 256. So, every key we > create is one less the application can use. This is really only a minor > concern. Most applications don't use thread local storage and those that > do don't usually need so many. We (the implementation) are always free to reserve a few extra on top of PTHREAD_KEYS_MAX just so libc doesn't consume application keys. If you or others are concerned about that, we can do this probably pretty easily. > 2. The order in which key destructors are called is not guaranteed. An > application that uses pthreads thread local storage for its own reasons and > calls one of the resolver routines from inside one of its destructors > could get in trouble because the destructor for the resolver routines > was called before its own. This would almost certainly lead to a memory > leak in the application. Hmm, true. Libc usage of pthread functions use the single underscore versions, so we could always differentiate between application keys and libc keys. libc keys could be destroyed last. Actually, we could automatically allocate a fixed amount of key space just for the implementation to use, so that it wouldn't detract from PTHREAD_KEYS_MAX and could be easily destroyed after the other keys. We should try to handle it the same way (libthr, libkse) if possible. Shoot me some email if you ever want to address the problem. -- Dan Eischen