From owner-freebsd-audit Mon Aug 12 5:28: 1 2002 Delivered-To: freebsd-audit@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F9B937B400; Mon, 12 Aug 2002 05:27:55 -0700 (PDT) Received: from alcatraz.iptelecom.net.ua (alcatraz.iptelecom.net.ua [212.9.224.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id E533743E8A; Mon, 12 Aug 2002 05:27:50 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Received: from relay.iptelecom.net.ua (alcatraz.iptelecom.net.ua [212.9.224.15]) by alcatraz.iptelecom.net.ua (8.9.3/8.9.3) with ESMTP id PAA20856; Mon, 12 Aug 2002 15:27:27 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Received: from vircheck.ipcard.iptcom.net (ipcard.iptcom.net [212.9.224.5]) by relay.iptelecom.net.ua (8.12.4/8.12.4) with ESMTP id g7CCRO8Y020796; Mon, 12 Aug 2002 15:27:24 +0300 (EEST) Received: from vega.vega.com (h210.234.dialup.iptcom.net [212.9.234.210]) by vircheck.ipcard.iptcom.net (8.12.3/8.12.3) with ESMTP id g7CCRIoQ021025; Mon, 12 Aug 2002 15:27:21 +0300 (EEST) Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vega.vega.com (8.12.5/8.11.3) with ESMTP id g7CCRHF2039805; Mon, 12 Aug 2002 15:27:17 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Message-ID: <3D57A9D4.DAA043EF@FreeBSD.org> Date: Mon, 12 Aug 2002 15:28:04 +0300 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,uk,ru MIME-Version: 1.0 To: Terry Lambert Cc: hackers@FreeBSD.ORG, audit@FreeBSD.ORG, Alexander Litvin , Andriy Gapon Subject: Re: Thread-safe resolver [patches for review] References: <3D578A99.F0821712@FreeBSD.org> <3D5792CD.497C80F0@mindspring.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry Lambert wrote: > > Maxim Sobolev wrote: > > Attched please find two patches based on bin/29581 PR to make FreeBSD > > resolver thread-safe. They represent two approaches to reach this goal > > - the first is to introduce reentrant versions of the standard > > gethostbyXXX(3) APIs, similar to ones existing in other unices, and > > the second one is to make gethostbyXXX(3) returning data placed into > > per-thread storage when linked with libc_r. I like the latter approach > > more, since it doesn't introduce new non-standard APIs. > > > > I would like to hear any comments and suggestions on the proposed > > patches, as well as to opinions about which path to chose. > > 1) Allocate the per thread storage as a single blob, and > set the pointers into it, instead of using seperate > allocations. This will have the side effect of letting > you free it, all at once, and will tend to make it > faster on each first use per thread, anyway. You can > do this by making a meta structure containing the list > of structures to be allocated, and then setting the > pointers to the addresses of the structure subelements. Ok, I'll do it. > 2) Note somewhere in the man page that this makes it so > you can not pass the results off to another thread by > reference, unless you copy them once there (i.e. you > are not allowed persistant references accross threads). > It seems to me the most likely use would be to permit > a seperate thread (or threads) to be used to resolve > concurrently, and/or with other operations. The upshot > of this is that holding a reference would mean that you > could not initiate another lookup on the lookup worker > thread(s) until the reference was freed. Yuip, I'll do it as well. > You may also want to consider the use of a .init and .fini > section for the code, to permit the creation of an initial > lookup context chunk; this is kind of a tradeoff, but it will > mean that a server will not have to do the recheck each time. > The .fini section would aloow auto-cleanup. This may be a > necessity for a long running program that uses a shared object > to perform the thread creation and lookup (you could leak > memory, otherwise). Could you please elaborate how exactly memory could be leaked in this case, if the program does correctly shut down all its threads? I also would like to hear from you whether or not you think that we need all those gethostbyXXX_r(3) functions. -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message