Green threads
=============

It would be nice if SLUL did not make assumptions on the type of threads
(i.e. "green threads" or "OS threads" or full-blown processes).
Also, for "OS threads" there are various differences between OS'es,
e.g. whether user ID's are a per-thread or per-process attribute.

Interopability with languages that use green threads:
* Use arenas as capabilities for growing the stack?
    - That way, it can be overridden.
    - BUT I've read that Go copies the stack when growing it,
      which would break all pointers to the stack. This is a
      problem for SLUL code.
* Restrict functions that don't take an arena parameter to allocate only
  a small amount of data on the stack (e.g. 2KiB).
    - And for complete correctness, we would have to analyze the maximum
      depth of recursive calls.

Interopability when using green threads and calling languages that 
use the SYSV ABI or otherwise expect a full stack:
* These calls could be "proxied" somehow via the arena. That way,
  a separate full-blown stack could be allocated during the function call.
    - This "proxying" could also provide increased security by using seccomp
      (or even running the code in an emulator written in safe SLUL code).