On 14 November 2010 02:09, Oswald Buddenhagen <o...@kde.org> wrote: > On Sat, Nov 13, 2010 at 11:28:08PM +0100, Lennart Poettering wrote: >> On Sat, 13.11.10 23:12, Mikkel Kamstrup Erlandsen >> (mikkel.kamst...@gmail.com) wrote: >> > I'd rather like something more deterministic. "When there are no >> > file handles on a file it's deleted" - might be too aggressive, but is >> > definitely clear cut :-) >> >> Well, except for the point that such a scheme is not really >> implementable on current OSes (neither is there an API to figure ot >> whether any process is referencing a file, and even if we had that >> things would be complex to do right, because you'd need an atomic >> 'delete-unless-referenced' syscall and stuff) and also not applicable to >> stuff like PID files for example. >> > i deem lsof sufficiently existent and applicable, even if a bit > inefficient as-is (hmm, isn't it possible to poll() /proc?). > and true atomicity would be somewhat overengineered, because in the > cases one can realistically expect, you don't have the situation where > an inode's only reference would be quickly passed between processes. but > you could still add some extra paranoia by polling every 10 minutes - if > a file is not referenced in three consecutive runs *and* the timestamp > didn't change since then, then declare it dead.
Yeah, I also had lsof in the back of my mind when writing that. There are also a few *totally* hacky ways to accomplish something similar (in order not to embarrass my self too much let me just hint "hard links + inotify" ;-)). But I did not intend to discuss the details of this particular proposal, it was just an example of a more clear cut rule that I think developers would understand- and account for more easily. After all, Lennart, you said yourself "If this also requires changes in another lower-level part of the OS (e.g. kernel) then this is completely fine". I take that as an invitation to brain storm :-) It also occurs to me that the "12h rule" appears a bit arbitrary - what kind of problems would it solve specifically? If $BUGGYBROWSER leaks a 100mb file each time it crashes my laptop would OOM way before 12 hours (example exaggerated for dramatic effect). And if you add to the spec that GC should be run when mem is low then you might as well specify that GC is completely up to the discretion of the session manager - which would make it a lot trickier to write "correct" consumers of XDG_RUNTIME_DIR. Alternatively, just put XDG_RUNTIME_DIR on conventional storage and the GC becomes more or less trivial. What are the exact benefits of putting it in RAM? -- Cheers, Mikkel _______________________________________________ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg