On Mon, Aug 13, 2001 at 01:18:52PM -0400, Daniel M. Eischen wrote:
> We don't provide locking for fd's any longer (I thought this was only in
> -current, but your results seem to indicate otherwise). If we did, only
> one thread would wake up. The mistake in your sample seems to be that
> you're having all threads block on the same fd. Why?
Consider a threaded server application, where N threads are blocking on
M descriptors (M>>N). The test code is merely a simplified version of this
scenario. I don't think this is a mistake, is it?
> We took the approach in -current that it is up to the application to
> provide locking for fd's. Our libc_r also wraps poll() into non-blocking
> calls which allows the other threads to run and "block" on the same
> fd. When we get blocking down in the kernel (KSEs or a linuxthreads
> like approach), I'm not exactly sure what would happen. From your
> results (linuxthreads under FreeBSD), it looks like it should behave
> as you expect.
Okay, I can understand why FreeBSD would do it this way, and why it might
be a good thing to leave it up to the application to provide the locking.
But on the flip side, it might be expensive to wake all the threads up when
only one has any real work to do.
I'm at a loss though, on how I could efficiently do locking so only one
thread actually read() on the fd. If I create a mutex per fd, and lock it
with one thread between poll() and read(), then other threads could do a
blocking lock on the mutex, which would decrease the benefits of threading;
or they could do non-blocking trylock's. In this case I could either make
the thread continue to poll as before (which might starve the thread with
the lock) or I can turn off polling on that fd (which might create a
situation where a thread polls for no fd's and never again wakes up). I
suppose I could be missing something incredibly simple, but where I stand
right now I don't see a solution...
Yes, I suppose I could just make the fd's non-blocking and catch the error
on read(), but that's not too convenient and I was hoping for some other
simple way to do this...
Incidentally, I'm still curious, what does the POSIX spec say all this?
-Jon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message