Date: Mon, 12 Aug 2002 03:49:49 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Maxim Sobolev <sobomax@FreeBSD.org> Cc: hackers@FreeBSD.org, audit@FreeBSD.org, Alexander Litvin <archer@whichever.org>, Andriy Gapon <agapon@excite.com> Subject: Re: Thread-safe resolver [patches for review] Message-ID: <3D5792CD.497C80F0@mindspring.com> References: <3D578A99.F0821712@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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. 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). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D5792CD.497C80F0>