[lkml]   [2000]   [Oct]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: kqueue microbenchmark results
    * Jamie Lokier <> [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

    -Alfred Perlstein - [|]
    "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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:45    [W:2.198 / U:0.344 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site