Date: Thu, 19 Jun 2003 23:01:57 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Mike Makonnen <mtm@identd.net> Cc: threads@freebsd.org Subject: Re: Removal of bogus gethostbyaddr_r() Message-ID: <Pine.GSO.4.10.10306192248160.4795-100000@pcnet5.pcnet.com> In-Reply-To: <20030620023348.PAID20810.pop015.verizon.net@kokeb.ambesa.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 19 Jun 2003, Mike Makonnen wrote: > On Thu, 19 Jun 2003 21:40:26 -0400 > Andriy Gapon <agapon@cv-nj.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10306192248160.4795-100000>