Skip site navigation (1)Skip section navigation (2)
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-hackers" 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>