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. 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. 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. E.g., one can map a zero page over the broken page, set a flag somewhere else saying "that data is corrupted", and then somewhere outside the inner processing loop, check the flag and abort the operation. But the sigaction interface is not flexible enough to make it safe to do this from library code in general, because signal handlers are process-wide. E.g., consider two libraries which both want safe access to memory-mapped files and are being invoked in different threads... AIUI, Windows's use of SEH is slightly better in this regard, since the relevant exception handler can be established using only local state. This still requires a compiler capable of emitting SEH frame establish/teardown code on Windows x86-32 (which had a patent fiasco a while back which may still be ongoing), and I think maybe appropriate unwind tables and framing on Windows x86-64, and it doesn't help the case of Unixy systems at all. ---> Drake Wilson _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
