On Thu, Apr 4, 2013 at 4:45 PM, Drake Wilson <dr...@dasyatidae.net> wrote: > Quoth Nico Williams <n...@cryptonector.com>, on 2013-04-04 16:08:24 -0500: >> This is very sad. But really, the OS should cause kvserv to hang >> waiting for I/O from the device to complete (and you should get some >> indication, in dmesg, on the console, in a dialog -something- that >> there's a missing device that's needed). Sending SIGBUS because a >> device is missing is a bit heavy-handed of the kernel! > > Well, the device is _gone_ from the perspective of the OS; the kernel > has no way of knowing whether I intend to plug that USB device back > in. The "removable media" aspect is a bit of a red herring; I am just > using that as a convenient way of inducing a mostly-repeatable read > failure at the hardware level. A more permanent case would be a bad > sector on a magnetic disk. It would not make any sense for the kernel > to pause the application indefinitely in case the sector can be > magically restored in the future.
This is off-topic, I know, so maybe we should continue this off-list, if at all, but... The OS could block the victim. If Linux prefers to SIGBUS the victim, well, that's Linux's fault, no? > In the case of read() or similar, you are already in a system call and > the kernel can return an error code which the application must already > know how to handle. In the case of mmap, what is interrupted is a > processor-level memory access, and there is no provision for returning > an error code; all that can be done is to reroute the entire control > flow, and on Unixy systems that is done using signals. Sure, EIO. But certainly for mmap() page faults it's best to hang. > Now, user code that can assume it controls the entire process _does_ > have the ability to establish a signal handler to fix up the access. Not an option here. Nico -- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
