Threads with graceful termination

[chrysn]

(I was about to open this on the RIOT side, but maybe the wrappers can do well enough on their own).

Currently, thread termination is a bit of a mess:

• Termination results can't be gathered
• We're handing out many things just under the condition that the thread never terminates
• We can't unwind in a panic (OK, that's a very advanced topic)
• Doing things through a PID is scary (and maybe should be unsafe, with the thread not having terminated as a hard to prove unsafety condition)

Consequently, threads are mostly run-once-and-hope-for-the-best to do useful things with them.

On Linux, each thread has a parent (orphaning to PID1) to whom it falls to obtain its exit code and clean it up.

---

Brainstorm sketchpad:

• Rust-created threads could do some signaling at end time (eg. unlock a mutex) to become awaitable. Then the owner of the memory can do shutdown -- but needs to consider both priority comparison results (for either it'll receive the signal while the mutex is dying, or it will receive the signal after the thread has reached its terminal (zombie, not closed for that'd be insta-reaped) state. That mutex could also indicate that some memory has been intialized with the thread's termination state (and while that state may easily reside inside the thread, practically it better be a location outside, for otherwise the position inside that thread would need to be communicate to the parent).

• A mutex can be awaited by one task; there could be a per-thread counter

• A thread flag NO_RETURN that indicates that the called function is __attribute__((noreturn)) / -> !, and thus any PID acquired is automatically longlived (and eligible for things like ... well what do we actually do with PIDs)

• Iterating PIDs like in ifconfig of ps: For stuff that doesn't block on other threads, like stack status, we could turn a pid-with-whatever-thread-it-points-to to a pid-that-points-to-the-thread-at-entry-time inside a critical section, and know to always talk to the same thread. An iterator inside a CS can already produce such advanced PIDs.

  • For netreg we have the read lock which allows doing that with less fall-out in #18740

• Once we can lock a thread from dying (by being its parent who'll reap a Rust-created thread, having incremented the use counter or knowing he thread is NO_RETURN), we can turn references from that thread into 'static types. That'd make them easy to send, eg. the freedom to use a thread as a message recipient (which we currently lease and return). It's like an Arc, just that all the variables from somewhere share a single RC, and it's only "freed" when all are freed.