From owner-freebsd-threads@FreeBSD.ORG Thu Aug 28 02:21:49 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 092E516A4BF; Thu, 28 Aug 2003 02:21:49 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3880043FFD; Thu, 28 Aug 2003 02:21:48 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfk56.dialup.mindspring.com ([165.247.208.166] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19sIyN-0003KL-00; Thu, 28 Aug 2003 02:21:44 -0700 Message-ID: <3F4DC971.498DD8F0@mindspring.com> Date: Thu, 28 Aug 2003 02:20:49 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Gordon Tetlow References: <20030827235853.GH695@roark.gnf.org> <20030828001120.GI695@roark.gnf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a43846a7df0d5c44a7cf89723c0a97a53f2601a10902912494350badd9bab72f9c350badd9bab72f9c cc: deischen@freebsd.org cc: threads@freebsd.org Subject: Re: Call for thread testers 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: Thu, 28 Aug 2003 09:21:49 -0000 Gordon Tetlow wrote: > > It could be that name resolution is giving it problems because > > it's not thread-safe (in libc)... > > Probably, but it is still a problem that needs to be addressed. Is it > possible to wrap the resolver in a umtx or some such other structure? The proper way to fix this, and the Netscape LDAP client libraries, until they are made reentrant, is to implement stub functions which lock a request queue, queue requests with monotonically increasing ID's, and then use a single library spawned worker thread in order to serially satisfy the queued requests (also queueing responses at the same time, using the ID corresponding to the request, so that it can be demux'ed back to the caller. Each caller would block on a per caller data structure condition variable, using an expandable pool of these structures in order to support an arbitrary number of calling threads. Microsoft calls this "apartment model threading". It's pretty trivial to do this; for an employer a while back, I did this for the Netscape LDAP client libraries to make them thread-safe. BTW: in case it wasn't obvious from the above, a mutex is exactly the wrong way to do this. Also: you may want to look into porting the Darwin lookupd; there was also a university which offered up their own version of a lookupd, the last time this question came up, which included caching to speed duplicate requests (an obvious win, for an http proxy server!), but no one took them up on their offer and committed the code. The main problem with a "thread safe resolver with the ability to handle an arbitrary number of client threads" is that you end up needing "an arbitrary number of UDP (and TCP, if the responses get large) sockets", which sucks. Better to serialize through one thread in an apartment model, and then expand the number of threads in the apartment to some administrative maximum concurrency, when the resolver code is rewritten. -- Terry