pthread: was genau macht "joinable" und was macht "detached"?

[HaWe]

Um so etwas komplett "abschiessen" zu können wäre ein Child Process [3][4] möglich. Damit könntest du das komplett abschießen und neu starten (Forken). Die Kommunikation würde dann über bsw. Fifo [2] laufen.

Ich empfehle dir das Buch: "The Linux Programming Interface: A Linux and UNIX System Programming Handbook"

Leider geht es nicht ohne Theorie. Wenn die Praxis nicht zur Theorie passt, läuft alles total schief und führt zu den verschiedensten Problemen. Computer verhalten sich nun mal nur logisch nach den definierten API's. Bsw. Posix.

[1] ISBN-13: 978-1593272203: The Linux Programming Interface: A Linux and UNIX System Programming Handbook
[2] https://linux.die.net/man/4/fifo
[3] https://linux.die.net/man/2/fork
[4] http://man7.org/linux/man-pages/man2/kill.2.html

Leider auch nur sehr theoretisch, die man pages kenne ich überwiegend schon; außerdem arbeite ich mit wiringPi und seinen file wrappern und seinen handles/fd's, nicht mit nativen files.
Was ich inzwischen aber heraus bekommen habe:
wenn ein realtime thread mit SCHED_RR prio 40 oder 50 hängt (Bereich: 0-99), komme ich auf einem single core Raspi (B+, Zero) überhaupt nicht mehr an irgend etwas heran: das gesamte Programm blockiert dann vollständig.
Auf einem multicore (2B, 3B) geht das schon besser, dann muss es aber wschl von einem höherwertigen thread aus passieren.
Unklar ist, wie SCHED_FIFO / _OTHER etc threads vom Scheduler behandelt werden gegenüber dem hängenden thread, und von einer main() loop aus wird es möglichereise auch nicht gehen, wenn weitere high prio threads laufen, denn (edit) die main loop läuft mit nice=0 (+20...-19, vergleichbar mit SCHED_OTHER (by default), hier gibt es keine prios), und kein Mensch weiß offensichtlich, wie die prios und nices untereinander verrechnet werden ).
Es wird also per zusätzlichem "watcher_thread" laufen müssen, d.h. von einer höheren SCHED_RR prio aus, und es dürfen wschl KEINE SCHED_FIFO threads laufen, wozu du verlinkt hast.

Er muss dann also über einen Thread mit SCHED_RR prio >50 laufen, der alle anderen überwacht (edit: z.B. prio 70-90, aber langen delays/yields zwischendurch),
von dort den anderen mit thread_kill() abbrechen,
dann UART (fd=Serial) beenden,
dann zusätzlich joinen, damit der threadID Handle gelöscht wird,
alles an Variablen /Semaphoren zurücksetzen,
dann UART (fd=Serial) sicher neu starten (geht das?),
dann den vorher abgebrochenen Thread neu starten (geht das mit dem früheren fd=Serial und der früheren threadID, jetzt neu zu vergeben?)
und dann muss die UART Verbindung sich neu mit dem Arduino re-syncen (geht das, auch wenn zwischendurch der virtuelle USB COM Port weg war?)

Ich vermute, viele wird es hier nicht geben, die sich mit der Materie tatsächlich auskennen und einen sicheren Beispielcode posten können, auch wenn ich es gehofft hatte...