blob: babee35f5628b2064a22e69c9eccfcdaef1b2370 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
|
How should `volatile` work?
===========================
Perhaps there are actually 4 different types of "volatile"
and "volatile"-like keywords:
* For multi-threading.
* For communicating with the OS, if that is done via reads/writes of
userspace rather than syscalls.
* For communicating with hardware, e.g. device registers.
* For signal handlers, setjmp/longjmp, etc.
Questions / decisions to make:
* Should `io` imply `volatile`?
- No, `io` objects can only be modified when the current thread
is operating on them (e.g. making a function call). Volatile
objects can be modified at any point, and even asynchronously.
* Should objects be able to become `volatile` when borrowed?
- No, next solution is better:
* Should `var` objects be able to become `volatile`?
- Perhaps. A `var` object is exclusively referenced (OR shared with
`aliased` references).
- But this would weaken `aliased`, which would essentially become
equivalent to `volatile`.
* Should only `volatile` and `io` objects be able to reference `volatile`
objects?
- Yes, this is necessary to prevent "spooky action at a distance",
or even incorrect behavior (e.g. a "pure" function that accesses
a `volatile` field somewhere).
* Should access to volatile data/fields only be allowed through
explicit "write_once" and "read_once" operators?
* Should 64-bit integers, float, and other possibly multiple-word sized
types be allowed in volatile data?
|
