Add "volatile" flag for untracked reads again?

[nikomatsakis]

We used to have a "volatile" flag that we placed on functions which may consume untracked inputs. At some point it was removed. Unfortunately, we don't seem to have authored an RFC at the time, so I don't remember the reasoning -- probably we could find a PR. The current method for signalling an untracked input is to invoke report_untracked_read on the runtime. It's a kind of "out of the way" API that most users will not find.

I think we should go back to the volatile flag, so that this...

#[tracked(volatile)]
fn foo(db: &dyn crate::Db) { }

...would be the way to signal an untracked read (and the public report_untracked_read function would be removed). There is no loss of expressiveness, as one can easily make a function (like foo above) that does nothing but report an untracked read, and decide dynamically whether to call it.

The reason that I think a flag is better:

• volatile and LRU don't mix well, as noted here. When we add the option for an LRU query (see Add options to tracked funcitons for lru capacity #344), we can make it an error to declare a query as both LRU and volatile, and then this logic won't be necessary (well, we'll probably keep that code, though we could change it to an assertion).

[nikomatsakis]

I just realized part of the problem here. There are operations that register untracked reads but which are not queries -- right now, reading an accumulator is one -- and so the "don't LRU if there are untracked inputs" code would still be needed. It might be nice, though, to just have the idea of a volatile query and not have untracked reads ever occur anywhere else, but at minimum we'd need to fix the accumulator dependency tracking, and there are probably other bits of motivation.

Still, there is some advantage to it: putting all operations that do untracked reads into a query helps ensure consistency, since the volatile function caches the result for the remainder of the revision (it is possible, of course, to have two queries that read the same underlying untracked value at different times and thus show inconsistent values from one another).

[macovedj]

#174 <--- seems to be the PR responsible for the switch

[nikomatsakis]

I'm thinking more about this.

I see some advantages to removing untracked reads as a function and instead requiring volatile queries:

• You avoid a performance footgun. When you have direct volatile reads now, that query result cannot be LRU'd, and the query is going to re-execute in each revision no matter what. If you force the untracked read to be encapsulated in a volatile query, we'll cache the result of that particular read and only re-execute that small piece of logic.

On the other hand, we'd have to check each place we do untracked reads and make sure that we can encapsulate them all into queries (e.g., accumulators today use untracked reads as a kind of "fallback").

Finally, I'm not sure that any of this matters in practice to real-world salsa projects.

On balance, I consider this a kind of low priority task, but it does have to be settled before we release a 1.0 because we can't easily take back the API.