Date: Tue, 12 Mar 1996 13:40:28 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: leisner@sdsp.mc.xerox.com (Marty Leisner) Cc: msmith@atrad.adelaide.edu.au, luigi@labinfo.iet.unipi.it, questions@freebsd.org Subject: Re: non-blocking read ? Message-ID: <199603122040.NAA06402@phaeton.artisoft.com> In-Reply-To: <9603121627.AA07775@gnu.mc.xerox.com> from "Marty Leisner" at Mar 12, 96 08:27:03 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > is there a simple way to issue a non-blocking read to a regular file ? > > > > > > Ideally, I would like a > > > > > > nbread(handle, buf, count); > > > > > > which would start reading from the disk, and could then notify > > > the completion of I/O via select(). > > > > Use async I/O and handle SIGIO like everybody else 8) > > > > > I don't know if fcntl() is enough: you can specify O_NONBLOCK for the > > > file, but then I have no idea if select() on that descriptor > > > would return immediately or will wait for at least one/the desired > > > amound of bytes to be available. > > > > Select may well behave strangely on regular files; at least I'd expect it > > to return immediately unless there's an EOF or error condition. > > Reads to regular files are non-blocking by default -- you either read > the next block or return EOF...note, they may take "time", but it isn't > like a socket or a pipe where you'd wait until something happens... I think he wants the equivalent of "aioread/aiowrite/aiowait/aiocancel"; this would let him interleave operations without waiting for the previous operation to be satisfied. Many database engines operate this way, and it was the primary implementation mechanism for the SunOS 4.x LWP facility. To implement this requires a minimal level of kernel reeentrancy, since a single process might post multiple requests. The read and write should have off_t arguments for where they are to take place instead of relying on the current position and/or seek pointer. I have a hard time believing (cv: previous posting in this thread) that "seek" takes any time at all -- a seek operation simply sets the offest into the struct file [the association of the offset with the vp at this level is probably incorrect; it's what causes the system open file table to consume multiple slots for multiple open instance to the same file: a mistake in design, in my book]. The "best" implementation would be as an alternate call gate to allow *all* system calls to be issues asynchronously (with a flag for iowait conditions set to 0 for calls that always operate on in core objects, like getuid/getpid/getgid/etc.). The implementation of "aio" calls is a second-best implemenation, but should be sufficient for Harvest (or even a single-process implementation of "team" or "ddd"). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603122040.NAA06402>