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
|
Fork safety
We need to guarantee that forks under fex are not more unsafe than forks of the native program itself.
In theory, multithreaded programs are not supposed to fork. In practice, it happens quite often.
Compilations:
### Deadlocks
If a thread other than the one doing the owns has any kind of lock, then that lock will never be unlocked in the forked program. Also, some locks may not gracefully handle forks (see: #1681). These issues also extend to any libraries FEX uses, including c/c++ runtimes, jemalloc, and others.
A partial solution to this is for the forking thread to own all the locks before fork, and for us to use custom lock implementations that are guaranteed to work across forks.
Currently, this is only done for the `FileManager` mutex. #1558 adds a generic place to do this for the syscalls handlers, and we need to go over all our os/frontend mutexes and add them there.
FEXCore itself doesn't have a callback for forks yet, that needs to be looked as well.
This could also be solved semi-automatically if we keep a list of all locks, possibly as part of our own custom lock type, though we need some way to define locking interdependencies and also interop with foreign lock types.
This is written with mutexes in mind, but it applies to all synchronization primitives, possibly including condvars, futexes, atomics, etc.
### Memory Leaks
When a thread forks, we need to drop all memory used by other threads. I haven't investigated to what extent that is done, and a possible efficient mechanism might be per thread memory pools with `madvise(MADV_DONTFORK)` and/or de-allocation callbacks to be called post-fork.
@phire worked on this previously, #889 contains some more information.
|