From owner-freebsd-hackers Thu Jan 25 9:36:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from sttlpop3.sttl.uswest.net (sttlpop3.sttl.uswest.net [206.81.192.3]) by hub.freebsd.org (Postfix) with SMTP id 43CAE37B699 for ; Thu, 25 Jan 2001 09:35:57 -0800 (PST) Received: (qmail 23574 invoked by alias); 25 Jan 2001 17:35:49 -0000 Delivered-To: fixup-freebsd-hackers@FreeBSD.ORG@fixme Received: (qmail 23514 invoked by uid 0); 25 Jan 2001 17:35:49 -0000 Received: from www.a6l.net (HELO a6l.net) (63.229.13.49) by sttlpop3.sttl.uswest.net with SMTP; 25 Jan 2001 17:35:49 -0000 Received: (qmail 72790 invoked by uid 1002); 25 Jan 2001 17:36:06 -0000 To: "Doug White" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: pthreads and kqueue References: From: Kevin Mills Date: 25 Jan 2001 09:36:05 -0800 In-Reply-To: "Doug White"'s message of "Wed, 24 Jan 2001 22:44:42 -0800 (PST)" Message-ID: <857l3jv8je.fsf@diablo.in.a6l.net> Lines: 28 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Doug White" writes: > On 24 Jan 2001, Kevin Mills wrote: > > You should probably assume that kqueue/kevent() & friends are not > thread-safe. I would suggest using a separate dispatcher thread that sits > on the kqueue and wakes up threads as needed. This would be much more > efficient than per-thread kqueues. 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). > 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! Thanks for your reply. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message