On Jun 30, 2008, at 9:22 PM, Nathan Froyd wrote:
> On Mon, Jun 30, 2008 at 7:58 PM, Julian Stecklina
> <der_julian@...> wrote:
>> FYI, I opened a Linux kernel bug and it was almost instantly
>> Regarding the comment "It is weird that lisp has such a strange
>> file io
>> implementation.": Is there any rationale for doing file I/O this way?
> 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
I'd naively expect the example code to simply translate to the syscalls:
open -> fd, read -> "Mains", read -> EOF, close.
Basically, *less* whiz-bangy stuff, not more.
I expect the kernel developers would also consider it odd. But, as a
less world-shattering suggestion, I'll just note that select never
does anything useful whatsoever for regular files, so it's basically a
waste to ever call bother implicitly calling it in such cases.