Messages in this thread |  | | Date | Fri, 27 Oct 2000 09:03:53 -0700 | From | Alfred Perlstein <> | Subject | Re: kqueue microbenchmark results |
| |
* Jamie Lokier <lk@tantalophile.demon.co.uk> [001027 08:21] wrote: > Alfred Perlstein wrote: > > > If a programmer does not ever wish to block under any circumstances, it's > > > his obligation to communicate this desire to the implementation. Otherwise, > > > the implementation can block if it doesn't have data or an error available > > > at the instant 'read' is called, regardless of what it may have known or > > > done in the past. > > > > Yes, and as you mentioned, it was _bugs_ in the operating system > > that did this. > > Not for writes. POLLOUT may be returned when the kernel thinks you have > enough memory to do a write, but someone else may allocate memory before > you call write(). Or does POLLOUT not work this way?
POLLOUT checks the socketbuffer (if we're talking about sockets), and yes you may still block on mbuf allocation (if we're talking about FreeBSD) if the socket isn't set non-blocking. Actually POLLOUT may be set even if there isn't enough memory for a write in the network buffer pool.
> For read, you still want to declare the sockets non-blocking so your > code is robust on _other_ operating systems. It's pretty straightforward.
Yes, it's true, not using non-blocking sockets is like ignoring friction in a physics problem, but assuming you have complete control over the machine it shouldn't trip you up that often. And we're talking about readability, not writeability which as you mentioned may block because of contention for the network buffer pool.
-- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |