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_attr_destroy.3p (9235B)


  1. '\" et
  2. .TH PTHREAD_ATTR_DESTROY "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_attr_destroy,
  12. pthread_attr_init
  13. \(em destroy and initialize the thread attributes object
  14. .SH SYNOPSIS
  15. .LP
  16. .nf
  17. #include <pthread.h>
  18. .P
  19. int pthread_attr_destroy(pthread_attr_t *\fIattr\fP);
  20. int pthread_attr_init(pthread_attr_t *\fIattr\fP);
  21. .fi
  22. .SH DESCRIPTION
  23. The
  24. \fIpthread_attr_destroy\fR()
  25. function shall destroy a thread attributes object. An implementation
  26. may cause
  27. \fIpthread_attr_destroy\fR()
  28. to set
  29. .IR attr
  30. to an implementation-defined invalid value. A destroyed
  31. .IR attr
  32. attributes object can be reinitialized using
  33. \fIpthread_attr_init\fR();
  34. the results of otherwise referencing the object after it
  35. has been destroyed are undefined.
  36. .P
  37. The
  38. \fIpthread_attr_init\fR()
  39. function shall initialize a thread attributes object
  40. .IR attr
  41. with the default value for all of the individual attributes used by a
  42. given implementation.
  43. .P
  44. The resulting attributes object (possibly modified by setting
  45. individual attribute values) when used by
  46. \fIpthread_create\fR()
  47. defines the attributes of the thread created. A single attributes
  48. object can be used in multiple simultaneous calls to
  49. \fIpthread_create\fR().
  50. Results are undefined if
  51. \fIpthread_attr_init\fR()
  52. is called specifying an already initialized
  53. .IR attr
  54. attributes object.
  55. .P
  56. The behavior is undefined if the value specified by the
  57. .IR attr
  58. argument to
  59. \fIpthread_attr_destroy\fR()
  60. does not refer to an initialized thread attributes object.
  61. .SH "RETURN VALUE"
  62. Upon successful completion,
  63. \fIpthread_attr_destroy\fR()
  64. and
  65. \fIpthread_attr_init\fR()
  66. shall return a value of 0; otherwise, an error number shall be returned
  67. to indicate the error.
  68. .SH ERRORS
  69. The
  70. \fIpthread_attr_init\fR()
  71. function shall fail if:
  72. .TP
  73. .BR ENOMEM
  74. Insufficient memory exists to initialize the thread attributes object.
  75. .P
  76. These functions shall not return an error code of
  77. .BR [EINTR] .
  78. .LP
  79. .IR "The following sections are informative."
  80. .SH EXAMPLES
  81. None.
  82. .SH "APPLICATION USAGE"
  83. None.
  84. .SH RATIONALE
  85. Attributes objects are provided for threads, mutexes, and condition
  86. variables as a mechanism to support probable future standardization in
  87. these areas without requiring that the function itself be changed.
  88. .P
  89. Attributes objects provide clean isolation of the configurable aspects
  90. of threads. For example, ``stack size''
  91. is an important attribute of a thread, but it cannot be expressed
  92. portably. When porting a threaded program, stack sizes often need to
  93. be adjusted. The use of attributes objects can help by allowing the
  94. changes to be isolated in a single place, rather than being spread
  95. across every instance of thread creation.
  96. .P
  97. Attributes objects can be used to set up ``classes' of threads with
  98. similar attributes; for example, ``threads with large stacks and high
  99. priority'' or ``threads with minimal stacks''. These classes can be
  100. defined in a single place and then referenced wherever threads need to
  101. be created. Changes to ``class'' decisions become straightforward, and
  102. detailed analysis of each
  103. \fIpthread_create\fR()
  104. call is not required.
  105. .P
  106. The attributes objects are defined as opaque types as an aid to
  107. extensibility. If these objects had been specified as structures,
  108. adding new attributes would force recompilation of all multi-threaded
  109. programs when the attributes objects are extended; this might not be
  110. possible if different program components were supplied by different
  111. vendors.
  112. .P
  113. Additionally, opaque attributes objects present opportunities for
  114. improving performance. Argument validity can be checked once when
  115. attributes are set, rather than each time a thread is created.
  116. Implementations often need to cache kernel objects that are expensive
  117. to create. Opaque attributes objects provide an efficient mechanism to
  118. detect when cached objects become invalid due to attribute changes.
  119. .P
  120. Since assignment is not necessarily defined on a given opaque type,
  121. implementation-defined default values cannot be defined in a portable
  122. way. The solution to this problem is to allow attributes objects to be
  123. initialized dynamically by attributes object initialization functions,
  124. so that default values can be supplied automatically by the
  125. implementation.
  126. .P
  127. The following proposal was provided as a suggested alternative to the
  128. supplied attributes:
  129. .IP " 1." 4
  130. Maintain the style of passing a parameter formed by the
  131. bitwise-inclusive OR of flags to the initialization routines (\c
  132. \fIpthread_create\fR(),
  133. \fIpthread_mutex_init\fR(),
  134. \fIpthread_cond_init\fR()).
  135. The parameter containing the flags should be an opaque type for
  136. extensibility. If no flags are set in the parameter, then the objects
  137. are created with default characteristics. An implementation may
  138. specify implementation-defined flag values and associated behavior.
  139. .IP " 2." 4
  140. If further specialization of mutexes and condition variables is
  141. necessary, implementations may specify additional procedures that
  142. operate on the
  143. .BR pthread_mutex_t
  144. and
  145. .BR pthread_cond_t
  146. objects (instead of on attributes objects).
  147. .P
  148. The difficulties with this solution are:
  149. .IP " 1." 4
  150. A bitmask is not opaque if bits have to be set into bitvector
  151. attributes objects using explicitly-coded bitwise-inclusive OR
  152. operations. If the set of options exceeds an
  153. .BR int ,
  154. application programmers need to know the location of each bit. If bits
  155. are set or read by encapsulation (that is, get and set functions), then
  156. the bitmask is merely an implementation of attributes objects as
  157. currently defined and should not be exposed to the programmer.
  158. .IP " 2." 4
  159. Many attributes are not Boolean or very small integral values. For
  160. example, scheduling policy may be placed in 3-bit or 4-bit, but
  161. priority requires 5-bit or more, thereby taking up at least 8 bits out
  162. of a possible 16 bits on machines with 16-bit integers. Because of
  163. this, the bitmask can only reasonably control whether particular
  164. attributes are set or not, and it cannot serve as the repository of the
  165. value itself. The value needs to be specified as a function parameter
  166. (which is non-extensible), or by setting a structure field (which is
  167. non-opaque), or by get and set functions (making the bitmask a
  168. redundant addition to the attributes objects).
  169. .P
  170. Stack size is defined as an optional attribute because the very notion
  171. of a stack is inherently machine-dependent. Some implementations may
  172. not be able to change the size of the stack, for example, and others
  173. may not need to because stack pages may be discontiguous and can be
  174. allocated and released on demand.
  175. .P
  176. The attribute mechanism has been designed in large measure for
  177. extensibility. Future extensions to the attribute mechanism or to any
  178. attributes object defined in this volume of POSIX.1\(hy2017 has to be done with care so
  179. as not to affect binary-compatibility.
  180. .P
  181. Attributes objects, even if allocated by means of dynamic allocation
  182. functions such as
  183. \fImalloc\fR(),
  184. may have their size fixed at compile time. This means, for example, a
  185. \fIpthread_create\fR()
  186. in an implementation with extensions to
  187. .BR pthread_attr_t
  188. cannot look beyond the area that the binary application assumes is
  189. valid. This suggests that implementations should maintain a size field
  190. in the attributes object, as well as possibly version information, if
  191. extensions in different directions (possibly by different vendors) are
  192. to be accommodated.
  193. .P
  194. If an implementation detects that the value specified by the
  195. .IR attr
  196. argument to
  197. \fIpthread_attr_destroy\fR()
  198. does not refer to an initialized thread attributes object, it is
  199. recommended that the function should fail and report an
  200. .BR [EINVAL]
  201. error.
  202. .P
  203. If an implementation detects that the value specified by the
  204. .IR attr
  205. argument to
  206. \fIpthread_attr_init\fR()
  207. refers to an already initialized thread attributes object, it is
  208. recommended that the function should fail and report an
  209. .BR [EBUSY]
  210. error.
  211. .SH "FUTURE DIRECTIONS"
  212. None.
  213. .SH "SEE ALSO"
  214. .ad l
  215. .IR "\fIpthread_attr_getstacksize\fR\^(\|)",
  216. .IR "\fIpthread_attr_getdetachstate\fR\^(\|)",
  217. .IR "\fIpthread_create\fR\^(\|)"
  218. .ad b
  219. .P
  220. The Base Definitions volume of POSIX.1\(hy2017,
  221. .IR "\fB<pthread.h>\fP"
  222. .\"
  223. .SH COPYRIGHT
  224. Portions of this text are reprinted and reproduced in electronic form
  225. from IEEE Std 1003.1-2017, Standard for Information Technology
  226. -- Portable Operating System Interface (POSIX), The Open Group Base
  227. Specifications Issue 7, 2018 Edition,
  228. Copyright (C) 2018 by the Institute of
  229. Electrical and Electronics Engineers, Inc and The Open Group.
  230. In the event of any discrepancy between this version and the original IEEE and
  231. The Open Group Standard, the original IEEE and The Open Group Standard
  232. is the referee document. The original Standard can be obtained online at
  233. http://www.opengroup.org/unix/online.html .
  234. .PP
  235. Any typographical or formatting errors that appear
  236. in this page are most likely
  237. to have been introduced during the conversion of the source files to
  238. man page format. To report such errors, see
  239. https://www.kernel.org/doc/man-pages/reporting_bugs.html .