From: Julian S. <der...@we...> - 2008-06-30 21:43:29
|
Alastair Bridgewater <nye...@li...> writes: > What I expect is happening here is that the Linux kernel is using the > "data ready for reading" notification as a "file contents changed" > notification. This, of course, breaks SBCL's assumption of straight > POSIX semantics for select() on files. I ran into the same problem with > /proc/bus/usb/devices. Could that be seen as a Linux kernel bug? I condensed your description in a small C program: http://www1.inf.tu-dresden.de/~s1054849/kernbug.c A sample session: % ./kernbug /proc/cpuinfo Read 512 bytes. Read 512 bytes. Read 126 bytes. Read 0 bytes. EOF % ./kernbug /sys/class/power_supply/BAT0/type Read 8 bytes. Timeout... ^C Is there something that mandates that select returns immediately for a fd that is at the EOF ? I only see the following sentence in the man page: "A file descriptor is considered ready if it is possible to perform the corresponding I/O operation (e.g., read(2)) without blocking." > Note that this would mean that you can hold a stream open to a file that > behaves this way, register an fd-handler on it for input, and recieve > notification of when the file changes via serve-event. This does not seem to work. > The only way that I can think of to have SBCL do "The Right Thing" with > files that behave in this manner is for there to be some method whereby > it can determine for itself if a file descriptor actually has this > particular set of brain-damaged semantics ahead of time, and raise > end-of-file instead of entering wait-until-fd-usable on such files. I > don't know of such a method, but that's more indicative of my not having > looked for one than anything else. IMHO it seems to be Linux' fault. Regards, -- Julian Stecklina Well, take it from an old hand: the only reason it would be easier to program in C is that you can't easily express complex problems in C, so you don't. - Erik Naggum (in comp.lang.lisp) (Spam-Experiment: http://cthulhu.c3d2.de/~astro/badpit.html ) |