[RFC] XDG_RUNTIME_DIR

[Mikkel Kamstrup Erlandsen]

On 14 November 2010 02:09, Oswald Buddenhagen <ossi at 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.kamstrup at 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