blob: 99e921a78a3dadb27d182ccf9a0a1cf3a363472a (
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
|
arenas: "colored function" and "duplicate implementation" problems
==================================================================
Functions that allocate in arenas versus functions that allocate owned
references is a kind of "colored function" problem, and also a "duplicate
implementation" problem.
What would be really nice to do is:
1. Allow functions that work with (take and return) arenas
to also work on a special "pseudo arena" that instead
allocates with standard malloc/free-style functions.
--> This would solve the "duplicate implementation" problem.
2. Allow functions that take only owned/non-arena references to somehow
also work with arenas (and call suchs functions).
--> This would solve the "colored function" problem.
Possible solutions:
- Use a thread local variable to hold the arena pointer.
(How can we use multiple arenas in one function in that case?)
- Add separate parameters for the arenas.
- "Lightweight arenas"? (see lightweight_arenas.txt)
- more...?
Partial solutions:
- For "arena any followme" style parameters, we could accept a NULL parameter
to allocate with malloc/free-style functions.
Tricky problem:
- arena allocation and malloc/free-style allocation is VERY different, and
cannot typically be merged into one implementation that supports both.
--> We could add a separate "either_arena_or_own" keyword for the basic
cases where it would work.
|
