Date: Thu, 28 Aug 2003 02:20:49 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Gordon Tetlow <gordont@gnf.org> Cc: threads@freebsd.org Subject: Re: Call for thread testers Message-ID: <3F4DC971.498DD8F0@mindspring.com> References: <20030827235853.GH695@roark.gnf.org> <20030828001120.GI695@roark.gnf.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F4DC971.498DD8F0>