logo

oasis-root

Compiled tree of Oasis Linux based on own branch at <https://hacktivis.me/git/oasis/> git clone https://anongit.hacktivis.me/git/oasis-root.git

pthread_exit.3p (4743B)

    

  1. '\" et
  2. .TH PTHREAD_EXIT "3P" 2017 "IEEE/The Open Group" "POSIX Programmer's Manual"
  3. .\"
  4. .SH PROLOG
  5. This manual page is part of the POSIX Programmer's Manual.
  6. The Linux implementation of this interface may differ (consult
  7. the corresponding Linux manual page for details of Linux behavior),
  8. or the interface may not be implemented on Linux.
  9. .\"
  10. .SH NAME
  11. pthread_exit
  12. \(em thread termination
  13. .SH SYNOPSIS
  14. .LP
  15. .nf
  16. #include <pthread.h>
  17. .P
  18. void pthread_exit(void *\fIvalue_ptr\fP);
  19. .fi
  20. .SH DESCRIPTION
  21. The
  22. \fIpthread_exit\fR()
  23. function shall terminate the calling thread and make the value
  24. .IR value_ptr
  25. available to any successful join with the terminating thread. Any
  26. cancellation cleanup handlers that have been pushed and not yet popped
  27. shall be popped in the reverse order that they were pushed and then
  28. executed. After all cancellation cleanup handlers have been executed,
  29. if the thread has any thread-specific data, appropriate destructor
  30. functions shall be called in an unspecified order. Thread termination
  31. does not release any application visible process resources, including,
  32. but not limited to, mutexes and file descriptors, nor does it perform
  33. any process-level cleanup actions, including, but not limited to,
  34. calling any
  35. \fIatexit\fR()
  36. routines that may exist.
  37. .P
  38. An implicit call to
  39. \fIpthread_exit\fR()
  40. is made when a thread other than the thread in which
  41. \fImain\fR()
  42. was first invoked returns from the start routine that was used to
  43. create it. The function's return value shall serve as the thread's
  44. exit status.
  45. .P
  46. The behavior of
  47. \fIpthread_exit\fR()
  48. is undefined if called from a cancellation cleanup handler or
  49. destructor function that was invoked as a result of either an implicit
  50. or explicit call to
  51. \fIpthread_exit\fR().
  52. .P
  53. After a thread has terminated, the result of access to local (auto)
  54. variables of the thread is undefined. Thus, references to local
  55. variables of the exiting thread should not be used for the
  56. \fIpthread_exit\fR()
  57. .IR value_ptr
  58. parameter value.
  59. .P
  60. The process shall exit with an exit status of 0 after the last thread
  61. has been terminated. The behavior shall be as if the implementation
  62. called
  63. \fIexit\fR()
  64. with a zero argument at thread termination time.
  65. .SH "RETURN VALUE"
  66. The
  67. \fIpthread_exit\fR()
  68. function cannot return to its caller.
  69. .SH ERRORS
  70. No errors are defined.
  71. .LP
  72. .IR "The following sections are informative."
  73. .SH EXAMPLES
  74. None.
  75. .SH "APPLICATION USAGE"
  76. None.
  77. .SH RATIONALE
  78. The normal mechanism by which a thread terminates is to return from the
  79. routine that was specified in the
  80. \fIpthread_create\fR()
  81. call that started it. The
  82. \fIpthread_exit\fR()
  83. function provides the capability for a thread to terminate without
  84. requiring a return from the start routine of that thread, thereby
  85. providing a function analogous to
  86. \fIexit\fR().
  87. .P
  88. Regardless of the method of thread termination, any
  89. cancellation cleanup handlers that have been pushed and not yet popped
  90. are executed, and the destructors for any existing thread-specific data
  91. are executed. This volume of POSIX.1\(hy2017 requires that cancellation cleanup handlers be
  92. popped and called in order. After all cancellation cleanup handlers have
  93. been executed, thread-specific data destructors are called, in an
  94. unspecified order, for each item of thread-specific data that exists in
  95. the thread. This ordering is necessary because cancellation cleanup
  96. handlers may rely on thread-specific data.
  97. .P
  98. As the meaning of the status is determined by the application (except
  99. when the thread has been canceled, in which case it is
  100. PTHREAD_CANCELED),
  101. the implementation has no idea what an illegal status value is, which
  102. is why no address error checking is done.
  103. .SH "FUTURE DIRECTIONS"
  104. None.
  105. .SH "SEE ALSO"
  106. .IR "\fIexit\fR\^(\|)",
  107. .IR "\fIpthread_create\fR\^(\|)",
  108. .IR "\fIpthread_join\fR\^(\|)"
  109. .P
  110. The Base Definitions volume of POSIX.1\(hy2017,
  111. .IR "\fB<pthread.h>\fP"
  112. .\"
  113. .SH COPYRIGHT
  114. Portions of this text are reprinted and reproduced in electronic form
  115. from IEEE Std 1003.1-2017, Standard for Information Technology
  116. -- Portable Operating System Interface (POSIX), The Open Group Base
  117. Specifications Issue 7, 2018 Edition,
  118. Copyright (C) 2018 by the Institute of
  119. Electrical and Electronics Engineers, Inc and The Open Group.
  120. In the event of any discrepancy between this version and the original IEEE and
  121. The Open Group Standard, the original IEEE and The Open Group Standard
  122. is the referee document. The original Standard can be obtained online at
  123. http://www.opengroup.org/unix/online.html .
  124. .PP
  125. Any typographical or formatting errors that appear
  126. in this page are most likely
  127. to have been introduced during the conversion of the source files to
  128. man page format. To report such errors, see
  129. https://www.kernel.org/doc/man-pages/reporting_bugs.html .