Date: Fri, 26 Jan 2001 11:12:59 -0800 (PST) From: Doug White <dwhite@resnet.uoregon.edu> To: Kevin Mills <kmills@a6l.net> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: pthreads and kqueue Message-ID: <Pine.BSF.4.21.0101261111420.1339-100000@resnet.uoregon.edu> In-Reply-To: <857l3jv8je.fsf@diablo.in.a6l.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0101261111420.1339-100000>