GMappedFile "disappearing mapping" handler
Submitted by Allison (desrt)
Link to original bug (#551278)
Description
consider this case:
- plug in a USB key
- open a gmappedfile off of that USB key
- yank the key
- go to read the memory region
currently you'll crash.
in theory, we could do better than this:
we'll get a signal on the read (probably sigbus or sigsegv or something, depending on the platform) and we can catch that. using siginfo we can probably (again, depending on the platform) determine the address that caused the crash. we could look up if that corresponded to any GMappedFile. if so, we could replace the missing page with a zero-filled page to give the user something to read without crashing, then mark the GMappedFile as 'invalid'.
this proposal would add a new very fast API: g_mapped_file_is_valid()
g_mapped_file_is_valid(mapped) { return mapped->valid; /* this is set to '0' from the signal handler */ }
then you could do IO against the mapped file with error checking:
do_io () { read memory read memory read memory
if (!g_mapped_file_is_valid ()) /* notice the error */; }
this is far better than crashing.
this raises a few interesting questions, though: what if GMappedFile isn't the only part of the program that wants to "notice" SIGBUS. perhaps some sort of address-based sigbus multiplexing is in order as a public glib API. you register a handler for a given memory region. GMappedFile could use this for any memory region it "owns" and so could anyone else who wanted to....
maybe this is too complicated and we should just say "don't ever use GMappedFile on any kind of removeable media or you risk crashing" (which is the current reality).
something to think about.