"Doug White" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
