From: Nathan F. <fr...@gm...> - 2008-07-01 03:09:59
|
On Mon, Jun 30, 2008 at 10:36 PM, James Y Knight <fo...@fu...> wrote: > On Jun 30, 2008, at 9:22 PM, Nathan Froyd wrote: >> I'd be curious as to what other way one would do file I/O if you want >> to support doing I/O on multiple sockets and files simultaneously. I >> mean, this has worked for *years*. (And no, whiz-bangy Linux-specific >> stuff doesn't count at the moment, at least not until something like >> iolib lands in SBCL.) > > Well, I guess I've always found it a bit odd that SBCL enters a serve-event > loop in all the places where it does. If you're just trying to read a file, > it seems like it should just read the file. I actually find the recursive > invocations of serve-event in random places to be irritating, not useful. It > makes it hard to reason about how the program is going to execute if > arbitrary code can be executed just about anywhere. Agreed. But if you're not going to differentiate between "file" fd-streams and "network socket" fd-streams, can you do any better? (Note that some people do this differentiation, probably for reasons like the ones you describe and/or running on strange OSes--not Windows, things like AIX. IBM's Jalapeno, for instance, only does non-blocking I/O on network socket streams, so presumably there's a flag *somewhere* that gets switched on.) One wonders if the I/O subsystem would be any faster if these extra syscalls went away. FD-STREAM does have a FILE member that appears to only be set for files...so some of the bits are there already... -Nathan |