[lkml]   [2002]   [Jul]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: more thoughts on a new jail() system call
    Thunder from the hill <> writes:

    > Hi,
    > On 19 Jul 2002, James Antill wrote:
    > > The more general spelling is FIONREAD, and I generally find that only
    > > crap network applications need to use it. Good ones just try and read
    > > a largish amount of data into a buffer.
    > That doesn't matter as long as you haven't got any idea on how much data
    > will be read. Especially relaying between two completely different hosts,
    > possibly unknown protocols, you don't have a chance to know who will send
    > next. Without TIOCINQ you'll almost be shot if you have received lots of
    > lots of stuff from the client and expect any response from the server. You
    > just won't get it.
    > Give me another version of the appended piece of code that won't use
    > ioctl, and I'll consider an acknowledgement.

    Hey, why not I'm bored[1] and have half an hour...

    Here it is, both libraries needed can be got from
    (I know socket_poll still requires gnome-config ... I'll get around to
    changing it to pkg-config soonish).

    Here's a quick list of differences[2]...

    1. Your version can _lose data_ when not all of the data from recv is
    sent down send.

    2. Your version _loses data_ when '\0' characters are in either

    3. Your version can easily get stuck doing work for just one
    direction, while the other direction is ignored.

    4. Your version has to use usleep() because you've done manual
    polling using ioctl(FIONREAD). Welcome to latency hell.

    ...points 1 and 3 will heavily suggest some kind of buffering
    mechanism and non-blocking read/write calls. That means you'll end up
    only using ioctl() for a ready/error state indicator.
    To fix point 4 you'll need to use poll()/etc. to get a ready/error state.
    Thus your program now being not too bad ... won't need to use

    [1] But not bored enough to write everything without using some decent
    libraries ... so sue me.

    [2] There are a couple of differences in error reporting, Ie. mine
    reports "read (*): No space left on device" when one of the
    connections is closed ... yours presumably fails from ioctl(). If I
    cared the code would be much different and be able to accept multiple
    connections etc. but I don't.

    [unhandled content-type:application/octet-stream]
    # James Antill --
    * ^From: .*james@and\.org
     \ /
      Last update: 2005-03-22 13:27    [W:0.023 / U:206.128 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site