Date: 25 Jan 2001 09:36:05 -0800 From: Kevin Mills <kmills@a6l.net> To: "Doug White" <dwhite@resnet.uoregon.edu> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: pthreads and kqueue Message-ID: <857l3jv8je.fsf@diablo.in.a6l.net> In-Reply-To: "Doug White"'s message of "Wed, 24 Jan 2001 22:44:42 -0800 (PST)" References: <Pine.BSF.4.21.0101242235180.25771-100000@resnet.uoregon.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
"Doug White" <dwhite@resnet.uoregon.edu> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?857l3jv8je.fsf>