[1003.1(2016)/Issue7+TC2 0001292]: Add pthread_setname, pthread_getname
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1292 == Reported By:joelsherrill Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1292 Category: Base Definitions and Headers Type: Enhancement Request Severity: Comment Priority: normal Status: New Name: Joel Sherrill Organization: RTEMS.org User Reference: Section:pthread.h Page Number:NA - addition request Line Number:NA - addition request Interp Status: --- Final Accepted Text: == Date Submitted: 2019-09-27 19:37 UTC Last Modified: 2019-09-30 17:33 UTC == Summary:Add pthread_setname, pthread_getname == -- (0004581) GarrettWollman (reporter) - 2019-09-30 17:33 http://austingroupbugs.net/view.php?id=1292#c4581 -- Also, for those who are looking, FreeBSD spells this interface pthread_set_name_np() (with an underscore). Issue History Date ModifiedUsername FieldChange == 2019-09-27 19:37 joelsherrill New Issue 2019-09-27 19:37 joelsherrill Name => Joel Sherrill 2019-09-27 19:37 joelsherrill Organization => RTEMS.org 2019-09-27 19:37 joelsherrill Section => pthread.h 2019-09-27 19:37 joelsherrill Page Number => NA - addition request 2019-09-27 19:37 joelsherrill Line Number => NA - addition request 2019-09-30 08:49 Konrad_Schwarz Note Added: 0004573 2019-09-30 13:59 wlerch Note Added: 0004575 2019-09-30 16:55 shware_systems Note Added: 0004577 2019-09-30 17:23 wlerch Note Added: 0004578 2019-09-30 17:24 GarrettWollman Note Added: 0004579 2019-09-30 17:31 GarrettWollman Note Added: 0004580 2019-09-30 17:33 GarrettWollman Note Added: 0004581 ==
[1003.1(2016)/Issue7+TC2 0001292]: Add pthread_setname, pthread_getname
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1292 == Reported By:joelsherrill Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1292 Category: Base Definitions and Headers Type: Enhancement Request Severity: Comment Priority: normal Status: New Name: Joel Sherrill Organization: RTEMS.org User Reference: Section:pthread.h Page Number:NA - addition request Line Number:NA - addition request Interp Status: --- Final Accepted Text: == Date Submitted: 2019-09-27 19:37 UTC Last Modified: 2019-09-30 17:31 UTC == Summary:Add pthread_setname, pthread_getname == -- (0004580) GarrettWollman (reporter) - 2019-09-30 17:31 http://austingroupbugs.net/view.php?id=1292#c4580 -- If we were to add this interface (which would require one of TOG, IEEE, or ISO to sponsor it), the specification would have to be clear about the expected lifetime of the name argument to pthread_setname() -- some implementations pass the name to a system call, which takes a copy, whereas other implementations will store it in a data structure within the process. Issue History Date ModifiedUsername FieldChange == 2019-09-27 19:37 joelsherrill New Issue 2019-09-27 19:37 joelsherrill Name => Joel Sherrill 2019-09-27 19:37 joelsherrill Organization => RTEMS.org 2019-09-27 19:37 joelsherrill Section => pthread.h 2019-09-27 19:37 joelsherrill Page Number => NA - addition request 2019-09-27 19:37 joelsherrill Line Number => NA - addition request 2019-09-30 08:49 Konrad_Schwarz Note Added: 0004573 2019-09-30 13:59 wlerch Note Added: 0004575 2019-09-30 16:55 shware_systems Note Added: 0004577 2019-09-30 17:23 wlerch Note Added: 0004578 2019-09-30 17:24 GarrettWollman Note Added: 0004579 2019-09-30 17:31 GarrettWollman Note Added: 0004580 ==
[1003.1(2016)/Issue7+TC2 0001292]: Add pthread_setname, pthread_getname
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1292 == Reported By:joelsherrill Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1292 Category: Base Definitions and Headers Type: Enhancement Request Severity: Comment Priority: normal Status: New Name: Joel Sherrill Organization: RTEMS.org User Reference: Section:pthread.h Page Number:NA - addition request Line Number:NA - addition request Interp Status: --- Final Accepted Text: == Date Submitted: 2019-09-27 19:37 UTC Last Modified: 2019-09-30 17:23 UTC == Summary:Add pthread_setname, pthread_getname == -- (0004578) wlerch (reporter) - 2019-09-30 17:23 http://austingroupbugs.net/view.php?id=1292#c4578 -- Individual applications defining their own private TLS slots for this is not quite as useful as a system-wide mechanism known to libraries and debugging tools. If you're worried about bloat, the function could be required to exist but allowed to return ENOSYS. Issue History Date ModifiedUsername FieldChange == 2019-09-27 19:37 joelsherrill New Issue 2019-09-27 19:37 joelsherrill Name => Joel Sherrill 2019-09-27 19:37 joelsherrill Organization => RTEMS.org 2019-09-27 19:37 joelsherrill Section => pthread.h 2019-09-27 19:37 joelsherrill Page Number => NA - addition request 2019-09-27 19:37 joelsherrill Line Number => NA - addition request 2019-09-30 08:49 Konrad_Schwarz Note Added: 0004573 2019-09-30 13:59 wlerch Note Added: 0004575 2019-09-30 16:55 shware_systems Note Added: 0004577 2019-09-30 17:23 wlerch Note Added: 0004578 ==
[1003.1(2016)/Issue7+TC2 0001292]: Add pthread_setname, pthread_getname
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1292 == Reported By:joelsherrill Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1292 Category: Base Definitions and Headers Type: Enhancement Request Severity: Comment Priority: normal Status: New Name: Joel Sherrill Organization: RTEMS.org User Reference: Section:pthread.h Page Number:NA - addition request Line Number:NA - addition request Interp Status: --- Final Accepted Text: == Date Submitted: 2019-09-27 19:37 UTC Last Modified: 2019-09-30 17:24 UTC == Summary:Add pthread_setname, pthread_getname == -- (0004579) GarrettWollman (reporter) - 2019-09-30 17:24 http://austingroupbugs.net/view.php?id=1292#c4579 -- The operating systems that support this functionality report thread status and thread names through other standard tools such as ps. Applications find it useful to be able to report thread information in this manner, and the interface as specified is clearly widely accepted in implementations that do not share a common lineage. (Obviously, some implementations would not be able to provide this information to external processes, but that does not limit its utility as a portable interface for applications to supply this information.) I believe it is not supported as a thread attribute because the common usage in applications is to start multiple threads with the same attributes; they can use thread names to provide more information about what the threads are doing after they are created. pthread_setname_np() was added as the threaded equivalent of setproctitle() which is commonly used for this purpose in single-threaded applications. Issue History Date ModifiedUsername FieldChange == 2019-09-27 19:37 joelsherrill New Issue 2019-09-27 19:37 joelsherrill Name => Joel Sherrill 2019-09-27 19:37 joelsherrill Organization => RTEMS.org 2019-09-27 19:37 joelsherrill Section => pthread.h 2019-09-27 19:37 joelsherrill Page Number => NA - addition request 2019-09-27 19:37 joelsherrill Line Number => NA - addition request 2019-09-30 08:49 Konrad_Schwarz Note Added: 0004573 2019-09-30 13:59 wlerch Note Added: 0004575 2019-09-30 16:55 shware_systems Note Added: 0004577 2019-09-30 17:23 wlerch Note Added: 0004578 2019-09-30 17:24 GarrettWollman Note Added: 0004579 ==
[1003.1(2016)/Issue7+TC2 0001292]: Add pthread_setname, pthread_getname
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1292 == Reported By:joelsherrill Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1292 Category: Base Definitions and Headers Type: Enhancement Request Severity: Comment Priority: normal Status: New Name: Joel Sherrill Organization: RTEMS.org User Reference: Section:pthread.h Page Number:NA - addition request Line Number:NA - addition request Interp Status: --- Final Accepted Text: == Date Submitted: 2019-09-27 19:37 UTC Last Modified: 2019-09-30 16:55 UTC == Summary:Add pthread_setname, pthread_getname == -- (0004577) shware_systems (reporter) - 2019-09-30 16:55 http://austingroupbugs.net/view.php?id=1292#c4577 -- Personally, I don't see that thread state for all threads need to be bloated with reserving space for this pointer, as the desired action implies. A sprintf(s, "Thread Id: %ju-%ju", (uintmax_t) getpid(), (uintmax_t) pthread_self()) does the job also, generically, for debugging or monitoring display, and individual applications desiring a non-generic display string can use a TLS slot for the purpose, using whatever key name they want. Issue History Date ModifiedUsername FieldChange == 2019-09-27 19:37 joelsherrill New Issue 2019-09-27 19:37 joelsherrill Name => Joel Sherrill 2019-09-27 19:37 joelsherrill Organization => RTEMS.org 2019-09-27 19:37 joelsherrill Section => pthread.h 2019-09-27 19:37 joelsherrill Page Number => NA - addition request 2019-09-27 19:37 joelsherrill Line Number => NA - addition request 2019-09-30 08:49 Konrad_Schwarz Note Added: 0004573 2019-09-30 13:59 wlerch Note Added: 0004575 2019-09-30 16:55 shware_systems Note Added: 0004577 ==
[1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1234 == Reported By:stephane Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1234 Category: Shell and Utilities Type: Enhancement Request Severity: Editorial Priority: normal Status: Interpretation Required Name: Stephane Chazelas Organization: User Reference: Section:2.13.1 Page Number:2382 Line Number:76212-76215 Interp Status: Pending Final Accepted Text:http://austingroupbugs.net/view.php?id=1234#c4564 == Date Submitted: 2019-03-08 23:58 UTC Last Modified: 2019-09-30 16:05 UTC == Summary:in most shells, backslash doesn't have two meaning wrt pattern matching == Relationships ID Summary -- related to 0001190 backslash has two special meanings in t... related to 247 Add nullglob (null globbing) support to... related to 985 quote removal missing from case stateme... == -- (0004576) geoffclare (manager) - 2019-09-30 16:05 http://austingroupbugs.net/view.php?id=1234#c4576 -- As agreed in the Sep 30th teleconference, http://austingroupbugs.net/view.php?id=1234#c4564 has been updated to add the page 2384 line 76288 section 2.13.3 change. Issue History Date ModifiedUsername FieldChange == 2019-03-08 23:58 stephane New Issue 2019-03-08 23:58 stephane Name => Stephane Chazelas 2019-03-08 23:58 stephane Section => 2.13.1 2019-03-08 23:58 stephane Page Number => 2382 2019-03-08 23:58 stephane Line Number => 76212-76215 2019-03-11 02:42 kreNote Added: 0004296 2019-03-11 02:58 kreNote Edited: 0004296 2019-03-11 03:07 kreNote Edited: 0004296 2019-03-11 03:10 kreNote Added: 0004297 2019-03-11 03:16 kreNote Edited: 0004296 2019-03-11 03:23 kreNote Added: 0004298 2019-03-11 07:24 stephane Note Added: 0004300 2019-03-11 07:31 stephane Note Added: 0004301 2019-03-11 09:41 geoffclare Note Added: 0004303 2019-03-12 03:24 kreNote Added: 0004306 2019-03-12 03:37 kreNote Added: 0004307 2019-03-12 03:38 kreNote Deleted: 0004297 2019-03-12 09:13 Konrad_Schwarz Note Added: 0004309 2019-03-12 09:58 geoffclare Note Added: 0004310 2019-03-12 12:13 Don Cragun Note Edited: 0004306 2019-03-12 12:14 Don Cragun Note Edited: 0004306 2019-03-12 12:15 kreNote Added: 0004313 2019-03-12 12:16 Don Cragun Note Edited: 0004307 2019-03-12 12:23 kreNote Added: 0004314 2019-03-12 12:24 kreNote Edited: 0004314 2019-03-12 14:29 Konrad_Schwarz Note Added: 0004317 2019-03-12 14:56 kreNote Edited: 0004313 2019-03-12 14:58 kreNote Edited: 0004314 2019-03-12 15:11 kreNote Added: 0004318 2019-03-12 22:37 stephane Note Added: 0004319 2019-03-14 15:58 Don Cragun Relationship added related to 0001190 2019-06-14 07:32 geoffclare Note Added: 0004421 2019-06-15 11:42 stephane Note Edited: 0004300 2019-06-15 11:43 stephane
[1003.1(2016)/Issue7+TC2 0001292]: Add pthread_setname, pthread_getname
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1292 == Reported By:joelsherrill Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1292 Category: Base Definitions and Headers Type: Enhancement Request Severity: Comment Priority: normal Status: New Name: Joel Sherrill Organization: RTEMS.org User Reference: Section:pthread.h Page Number:NA - addition request Line Number:NA - addition request Interp Status: --- Final Accepted Text: == Date Submitted: 2019-09-27 19:37 UTC Last Modified: 2019-09-30 13:59 UTC == Summary:Add pthread_setname, pthread_getname == -- (0004575) wlerch (reporter) - 2019-09-30 13:59 http://austingroupbugs.net/view.php?id=1292#c4575 -- Debugging, as such, is out of scope, but building executables that enable debugging (c99 -g) doesn't seem to be. I would argue that setting thread names from code is on the same side of that line as the -g option. Issue History Date ModifiedUsername FieldChange == 2019-09-27 19:37 joelsherrill New Issue 2019-09-27 19:37 joelsherrill Name => Joel Sherrill 2019-09-27 19:37 joelsherrill Organization => RTEMS.org 2019-09-27 19:37 joelsherrill Section => pthread.h 2019-09-27 19:37 joelsherrill Page Number => NA - addition request 2019-09-27 19:37 joelsherrill Line Number => NA - addition request 2019-09-30 08:49 Konrad_Schwarz Note Added: 0004573 2019-09-30 13:59 wlerch Note Added: 0004575 ==
Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching
On 30/09/2019 12:00, Geoff Clare wrote: Harald van Dijk wrote, on 30 Sep 2019: (As an aside, why is this exception limited to patterns used for filename expansion? Existing practice is that it applies to all patterns: case [a in [*) echo match ;; *) echo no match ;; esac This prints "no match" in bosh, dash, ksh, and pdksh and posh.) Because it's not the exception you thought it was? If the one stated in 2.13.3 applied here, then it would apply to *[ as well as [*. It does apply to *[ as well as [* in most of those shells. That's surprising. case a[ in *[) echo match ;; *) echo no match ;; esac This still prints "no match" in bosh, ksh and pdksh and posh, so the exception in 2.13.3 should still apply here if it is intended to match existing shell behaviour. I think this should be raised as a separate bug. Since you are the person who noticed it, do you want to be the one to submit the bug? Okay, I will do so. Cheers, Harald van Dijk
Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching
Harald van Dijk wrote, on 30 Sep 2019: > >> > >>>If the pattern contains an open bracket ( '[' ) that does not introduce a > >>>bracket expression as in XBD RE Bracket Expression, it is unspecified > >>>whether other unquoted pattern matching characters within the same > >>>slash-delimited component of the pattern retain their special meanings or > >>>are treated as ordinary characters. For example, the pattern "a*[/b*" may > >>>match all filenames beginning with 'b' in the directory "a*[" or it may > >>>match all filenames beginning with 'b' in all directories with names > >>>beginning with 'a' and ending with '['. > >>This is because the shell may have already committed to parsing it as an > >>ordinary character as it was under the impression a bracket expression had > >>started. > > > >If that was the reason, wouldn't it only apply to characters after the '['? > >As per the example given - a*[/b* - it also applies to characters before it. > > Huh, I missed that. You're right. > > That raises another question: is it unspecified whether each individual > pattern character is treated literally, or all at once? That is, it is clear > that *[*/x* is permitted to list the file names starting with "x" in > directory "*[*", and it is permitted to list the file names starting with > "x" in directories with names containing "[", but is it also permitted to > list the file names starting with "x" in directories with names ending in > "[*"? All three behaviours can be found in current shells. The unspecified behaviour applies to each character individually. In order to require that they are all treated the same within a component, the standard would have to say so explicitly. > >>(As an aside, why is this exception limited to patterns used for filename > >>expansion? Existing practice is that it applies to all patterns: > >> > >> case [a in [*) echo match ;; *) echo no match ;; esac > >> > >>This prints "no match" in bosh, dash, ksh, and pdksh and posh.) > > > >Because it's not the exception you thought it was? If the one stated > >in 2.13.3 applied here, then it would apply to *[ as well as [*. > > It does apply to *[ as well as [* in most of those shells. That's surprising. > case a[ in *[) echo match ;; *) echo no match ;; esac > > This still prints "no match" in bosh, ksh and pdksh and posh, so the > exception in 2.13.3 should still apply here if it is intended to match > existing shell behaviour. I think this should be raised as a separate bug. Since you are the person who noticed it, do you want to be the one to submit the bug? -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching
On 30/09/2019 10:51, Geoff Clare wrote: Harald van Dijk wrote, on 28 Sep 2019: On 23/09/2019 16:39, Austin Group Bug Tracker wrote: -- (0004564) geoffclare (manager) - 2019-09-23 15:39 http://austingroupbugs.net/view.php?id=1234#c4564 -- [...] For the shell only, it is unspecified whether or not a character inside a bracket expression preserves the literal value of the following character. I noticed now that the resolution of bug 1233 was to not change the rules for how is treated inside bracket expressions (yet), but this does change it. This may be worth mentioning in bug 1233. "inside a bracket expression" is probably too narrow, given the exception in 2.13.3: bs='\' set -- ?[$bs.* 2.13.3 states that despite the * not being part of a bracket expression, it may be treated as an ordinary character: If the pattern contains an open bracket ( '[' ) that does not introduce a bracket expression as in XBD RE Bracket Expression, it is unspecified whether other unquoted pattern matching characters within the same slash-delimited component of the pattern retain their special meanings or are treated as ordinary characters. For example, the pattern "a*[/b*" may match all filenames beginning with 'b' in the directory "a*[" or it may match all filenames beginning with 'b' in all directories with names beginning with 'a' and ending with '['. This is because the shell may have already committed to parsing it as an ordinary character as it was under the impression a bracket expression had started. If that was the reason, wouldn't it only apply to characters after the '['? As per the example given - a*[/b* - it also applies to characters before it. Huh, I missed that. You're right. That raises another question: is it unspecified whether each individual pattern character is treated literally, or all at once? That is, it is clear that *[*/x* is permitted to list the file names starting with "x" in directory "*[*", and it is permitted to list the file names starting with "x" in directories with names containing "[", but is it also permitted to list the file names starting with "x" in directories with names ending in "[*"? All three behaviours can be found in current shells. (A perverse implementation could also list the file names starting with "x" in directories with names starting with "*[", but I cannot think of any legitimate reason why a shell would do that and I do not know any shell that does it.) 2.13.3 should be modified to also state that despite the indirect backslash not being part of a bracket expression, it is also unspecified whether it preserves the literal value of the following character here. I was reading "unquoted pattern matching characters" as including backslash, but it would make sense to spell it out by changing that bit to: ... whether other unquoted '*', '?', '[' or characters within the same ... That looks good to me. I did not think of backslash as a pattern matching character. The term does not have a definition, as far as I know, and backslash is no longer one of the characters that triggers pattern matching under the proposed bug resolution, but I can see how it could be read differently. appropriate.to:3. If a specified pattern contains any '*', '?' or '[' characters that will be treated as special (see [xref to 2.13.1]), it shall be matched against existing filenames and pathnames, as appropriate. How is this intended to interact with that exception in 2.13.3? For an unquoted [* word, this may either unconditionally produce "[*", or it may expand to the names of files starting with "[". In shells where it unconditionally produces "[*", does that mean pathname expansion is not performed, as none of the characters are treated as special? Or does "unspecified" mean it may be treated as a pattern matching character when determining whether pathname expansion is going to be performed, but then as a literal character during the actual pathname expansion? This is relevant if the [* is at the end of a larger pattern containing an indirect backslash. I would consider that to be a quality-of-implementation issue. A good quality implementation would ensure consistency between the precheck code to decide whether to match against pathnames and the actual pattern matching code. A poor quality one might not. Okay. The reason for asking was that depending on how certain unspecified aspects of pattern matching are handled, fully parsing bracket expressions, including character classes, equivalence classes and collating symbols in the precheck code is unnecessary, it is possible to limit the check to pathname components containing an unquoted ?, an unquoted *, or an unquoted [ that is later followed by an unquoted ] (with special exceptions for [] and [!]). Being able to leave the rest
[1003.1(2016)/Issue7+TC2 0001293]: Add methods associated with manipulating pthread affinity on SMP systems
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=1293
==
Reported By:joelsherrill
Assigned To:
==
Project:1003.1(2016)/Issue7+TC2
Issue ID: 1293
Category: Base Definitions and Headers
Type: Enhancement Request
Severity: Editorial
Priority: normal
Status: New
Name: Joel Sherrill
Organization: RTEMS.org
User Reference:
Section:pthread.h and add sys/cpuset.h
Page Number:NA - addition request
Line Number:NA - addition request
Interp Status: ---
Final Accepted Text:
==
Date Submitted: 2019-09-27 19:53 UTC
Last Modified: 2019-09-30 08:59 UTC
==
Summary:Add methods associated with manipulating pthread
affinity on SMP systems
==
--
(0004574) Konrad_Schwarz (reporter) - 2019-09-30 08:59
http://austingroupbugs.net/view.php?id=1293#c4574
--
I am pretty sure affinity was not included in Pthreads because the
heterogeneity of NUMA machines made it too difficult to define a useful
API.
I.e., code running on super computers ideally requires the ability to
figure
out the interconnection speed of cores: are two cores merely hardware
("hyper") threads, or co-located on the same chip,
or connected via a backplane?
Issue History
Date ModifiedUsername FieldChange
==
2019-09-27 19:53 joelsherrill New Issue
2019-09-27 19:53 joelsherrill Name => Joel Sherrill
2019-09-27 19:53 joelsherrill Organization => RTEMS.org
2019-09-27 19:53 joelsherrill Section => pthread.h and add
sys/cpuset.h
2019-09-27 19:53 joelsherrill Page Number => NA - addition
request
2019-09-27 19:53 joelsherrill Line Number => NA - addition
request
2019-09-30 08:59 Konrad_Schwarz Note Added: 0004574
==
[1003.1(2016)/Issue7+TC2 0001292]: Add pthread_setname, pthread_getname
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1292 == Reported By:joelsherrill Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1292 Category: Base Definitions and Headers Type: Enhancement Request Severity: Comment Priority: normal Status: New Name: Joel Sherrill Organization: RTEMS.org User Reference: Section:pthread.h Page Number:NA - addition request Line Number:NA - addition request Interp Status: --- Final Accepted Text: == Date Submitted: 2019-09-27 19:37 UTC Last Modified: 2019-09-30 08:49 UTC == Summary:Add pthread_setname, pthread_getname == -- (0004573) Konrad_Schwarz (reporter) - 2019-09-30 08:49 http://austingroupbugs.net/view.php?id=1292#c4573 -- I think the main rationale for excluding pthread names in Posix is that debugging (the prime consumer of such information) is out of scope. Issue History Date ModifiedUsername FieldChange == 2019-09-27 19:37 joelsherrill New Issue 2019-09-27 19:37 joelsherrill Name => Joel Sherrill 2019-09-27 19:37 joelsherrill Organization => RTEMS.org 2019-09-27 19:37 joelsherrill Section => pthread.h 2019-09-27 19:37 joelsherrill Page Number => NA - addition request 2019-09-27 19:37 joelsherrill Line Number => NA - addition request 2019-09-30 08:49 Konrad_Schwarz Note Added: 0004573 ==
