blob: 35aa65f35420afdb8bb5b3a56c834de2758ac982 (
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
35
|
"own" vs arenas
---------------
Problem:
- Should an "own" pointer be usable as an arena or not?
If yes, then:
- All "own" references must be allocated in arenas
- This simplifies the implementation (there is only one type of allocation)
- But it also become much harder to interoperate with C
(C pointers aren't arena pointers, but can be "own" pointers)
- This could be sovled by adding a new keyword for this special case.
If no, then:
- We will probably need to allow the combination of arena + own.
(should be either "arena own" or something else, and NOT "own arena"
which would be confusing).
- But this is also problematic, since we could actually have an
owned reference inside an arena, which would also be "arena own"
Basically, we need these levels:
- ref
- arena
- own-inside-arena (useful for resources that MUST be released)
- own-outside-arena
own-inside-arena adds some complexity:
- free'ing the arena must also free the "own"-qualified object.
- any references must have equal or shorter lifetime than the arena!
Having "own" references inside an arena OR on the stack is also complex,
because they need to be released in case the is an exception.
- They need to be tracked in the arena somehow (perhaps a linked list of
things to release / "destructor" functions to call).
|
