Pthreads

Line 7:

* The Triforce of POSIX Thread stacks:

** If you aren't allocating a stack fit to your thread, you will one day smash that stack.

** If you're using your stack, you should probably heap-allocate or use TLS.

** If you're using your stack, you should probably heap-allocate or use [[TLS]].

** Recursion's all fun and games until your recurse on through to the other side.

** Yes, this all applies to an unthreaded program (especially an embedded one), with a critical difference -- memory management is process-based, causing noisy failures in the unthreaded case. Meanwhile, a POSIX thread will happily push a frame down right over his buddy's DTV/TLS in NPTL (see [http://www.redhat.com/whitepapers/developer/POSIX_Linux_Threading.pdf NPTL], "Memory Allocation"). Have a good time debugging that, champ!

** Yes, this all applies to an unthreaded program (especially an embedded one), with a critical difference -- memory management is process-based, causing noisy failures in the unthreaded case. Meanwhile, a POSIX thread will happily push a frame down right over his buddy's DTV/[[TLS]] in NPTL (see [http://www.redhat.com/whitepapers/developer/POSIX_Linux_Threading.pdf NPTL], "Memory Allocation"). Have a good time debugging that, champ!

* Failure to check every return, especially pthread_mutex_destroy(), is cause for [http://en.wikipedia.org/wiki/Tuol_Sleng_Genocide_Museum#The_Security_Regulations many many lashes of electric wire].

* Those who fail to designate an alternate signal stack will one day wish they had.

Pthreads: Difference between revisions

Dank (talk | contribs)

@@ Line 7: / Line 7: @@
 * The Triforce of POSIX Thread stacks:
 ** If you aren't allocating a stack fit to your thread, you will one day smash that stack.
-** If you're using your stack, you should probably heap-allocate or use TLS.
+** If you're using your stack, you should probably heap-allocate or use [[TLS]].
 ** Recursion's all fun and games until your recurse on through to the other side.
-** Yes, this all applies to an unthreaded program (especially an embedded one), with a critical difference -- memory management is process-based, causing noisy failures in the unthreaded case. Meanwhile, a POSIX thread will happily push a frame down right over his buddy's DTV/TLS in NPTL (see [http://www.redhat.com/whitepapers/developer/POSIX_Linux_Threading.pdf NPTL], "Memory Allocation"). Have a good time debugging that, champ!
+** Yes, this all applies to an unthreaded program (especially an embedded one), with a critical difference -- memory management is process-based, causing noisy failures in the unthreaded case. Meanwhile, a POSIX thread will happily push a frame down right over his buddy's DTV/[[TLS]] in NPTL (see [http://www.redhat.com/whitepapers/developer/POSIX_Linux_Threading.pdf NPTL], "Memory Allocation"). Have a good time debugging that, champ!
 * Failure to check every return, especially pthread_mutex_destroy(), is cause for [http://en.wikipedia.org/wiki/Tuol_Sleng_Genocide_Museum#The_Security_Regulations many many lashes of electric wire].
 * Those who fail to designate an alternate signal stack will one day wish they had.