From owner-freebsd-hackers Fri Jan 26 11:13:22 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from resnet.uoregon.edu (resnet.uoregon.edu [128.223.122.47]) by hub.freebsd.org (Postfix) with ESMTP id 5939637B400 for ; Fri, 26 Jan 2001 11:13:02 -0800 (PST) Received: from localhost (dwhite@localhost) by resnet.uoregon.edu (8.10.1/8.10.1) with ESMTP id f0QJCx101741; Fri, 26 Jan 2001 11:12:59 -0800 (PST) Date: Fri, 26 Jan 2001 11:12:59 -0800 (PST) From: Doug White To: Kevin Mills Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: pthreads and kqueue In-Reply-To: <857l3jv8je.fsf@diablo.in.a6l.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 25 Jan 2001, Kevin Mills wrote: > Well, there are wrappers in the libc_r code (libc_r/uthread/uthread_kevent.c) > and I seem to recall posts on -stable saying that kqueue could now be used > with user threads (around the 4.1.1 time frame, I think). I could be wrong :) > > This seems like a strange way to implement your solution, though ... from > > the sounds of it, you can only have one concurrent connection to your > > authentication server via this library, which sounds extremely lame. Do > > the clients just sit around forever until the server returns? The > > serialization this library forces isn't too scalable. > > The library is reentrant and will allow different threads to call into > it (there isn't a mutex serializing the entry point or anything like that). > However, the call to the backend is done with a blocking call. The > communication with the backend is generally very quick. However, if the > backend gets too busy I want to make sure I don't starve the other connections. > A thread pool seemed the best way to tackle this. I'd be very open to other > suggestions if you have any! Also, your proprietary library has to be threadsafe too. Particularly if it blocks... it'll probably block the whole process instead of the individual thread. Unless we figured out a way to fix that :) Doug White | FreeBSD: The Power to Serve dwhite@resnet.uoregon.edu | www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message