We want the ability to provide attributes to thread (full threads: thread, jthread) constructors, even if we can't specify their semantics fully.
Yay 12, nay 1

The name attribute.
Yay 14 Nay 1

The stack size attribute.
Yay 7 Nay 7

Nay: round up the other authors (like Patrice) from before, that will improve my view of stack size.

P2019R1 Usability improvements for std::thread (Corentin Jabot)

P2019R2 Usability improvements for std::thread (Corentin Jabot)

Poll: Forward the thread name attribute design of P2019R2 to LEWG
(Return to SG1 for final wording when this is in LWG.)
SF F N A SA
10 5 0 0 0

Unanimous consent

Poll: Forward the thread stack size attribute design of P2019R2 to LEWG
(Return to SG1 for final wording when this is in LWG.)
SF F N A SA
4 7 3 1 0

Consensus

Poll: Open a CWG issue to have words in the standard that speak to runtime
limits like the # of automatic storage variables allowed
e.g. because of "stack size" (for example in Annex B)
SF F N A SA
8 6 0 0 1

Consensus
SA: it simply doesn't make sense

2023-01-24 ISO C++ Library Evolution Telecon

P2019R2: Thread Attributes

2023-01-24 Library Evolution Telecon Minutes

Champion: Corentin Jabot

Chair: Bryce Adelstein Lelbach

Minute Taker: Ben Craig

Start: 2023-01-24 11:12 Eastern

Does this paper have:

• Examples?
  • Yes.
• Field experience?
  • Implementation experience?
    • Yes, in libc++.
  • Usage experience?
    • Yes for stack size, in Boost Thread, but not from spec.
  • Deployment experience?
    • Yes for stack size, in Boost Thread, but not from spec.
• Performance considerations?
  • Yes.
• Discussion of prior art?
  • Yes, including C++ libraries (Boost, Qt) and other languages (Rust, Java, Python, etc).
• Changes Library Evolution previously requested?
  • Yes.
• Wording?
  • Yes.
• Breaking changes?
  • The paper claims this is not a breaking change.
• Feature test macro?
  • Yes.
• Freestanding?
  • Yes.

What are considered valid thread stack sizes and thread names? Do we specify anything about that? If I use an invalid thread stack size or name, do I get an exception? Is it undefined behavior? Can the thread stack size or name be silently ignored?

Are thread stack sizes specified to be in bytes, or is it intentionally unitless?

Why no thread priority in this proposal? Because they vary across platforms and we don't know how to specify them portably.

Does using a capturing lambda instead of the function + arguments constructor have a performance penalty? The author indicates it should not.

What is the "Recommended Practice" clause used in the wording? Is that new?

What do the major implementers think about these proposed features?

Should thread stack size and names be compile time parameters?

Is std::jthread(std::thread_name("X"), std::thread_name("Y")) well formed? If so, what is the name of the thread?

What if I want to start a thread with a function that takes an attribute?

There may be ambiguities between the function + attributes and function + arguments constructors.

• std::jthread([](auto...){}, std::thread_name("X"), std::thread_stack_size(1024)) -> calls new function + attributes constructor.
• std::jthread([](auto...){}, std::thread_name("X"), 1024) -> Calls old function + arguments constructor.

Topics to Polls:

• Attributes + arguments constructor.
• New function + variadic attributes constructor vs new function + single aggregate attributes parameter.
• New function + variadic attributes constructor vs factory function.
• Separate types for each attribute vs monolithic attribute type.
• Setting attributes after thread creation.
• Querying attributes after thread creation.

POLL: The initial release of standard library thread attributes should have thread priorities.

Attendance: 21

# of Authors: 1

Author Position: SA

Outcome: Weak consensus against.

POLL: The initial release of standard library thread attributes should have a query for a thread's name.

Attendance: 21

# of Authors: 1

Author Position: SA

Outcome: No consensus.

POLL: The initial release of standard library thread attributes should allow a thread's name to be set after thread construction.

Attendance: 21

# of Authors: 1

Author Position: SA

Outcome: No consensus.

POLL: Add a factory function for constructing threads with attributes instead of adding a new constructor.

Attendance: 21

# of Authors: 1

Author Position: N

Outcome: No consensus.

WA: I don't understand why a factory function would be necessary based on the discussion. I could be convinced, but I'm veering towards simplicity.

POLL: The mechanism for constructing threads with attributes should take arguments to the thread function in addition to attributes.

Attendance: 21

# of Authors: 1

Author Position: SA

Outcome: No consensus.

WA: I'm concerned about the complexity this would add and I think it's unnecessary; you can just use a lambda with captures.

POLL: Thread attributes should be passed as a single aggregated argument instead of being passed as variadic arguments.

Attendance: 21

# of Authors: 1

Author Position: SA

Outcome: No consensus.

End: 12:24

Summary

This paper proposes adding thread attributes to (j)thread, specifically thread names and thread stack sizes.

We talked considered what the scope of this proposal should be. Should thread priorities be included? Should we be able to query attributes of a thread? Should we be able to set them after construction? After discussion, we had consensus to exclude thread priorities, but we had no consensus on querying and setting attributes after construction.

We also discussed the API for setting attributes on thread construction. The current proposal adds a new constructor that takes a thread function and a variadic pack of attributes, but no arguments for the thread function. Some suggested that the constructor should take both attributes and function arguments.

There was a concern that the new constructor could be unclear - are the arguments to a (j)thread constructor call passed to the thread function, or treated as thread attributes? It was suggested that we should consider ways to combine all the attributes into a single argument, although the author believes this presents challenges and may have ABI implications. Another idea was to add a factory function instead of a new constructor.

Our review and polling made it clear that Library Evolution is still undecided about many of the major design choices about this feature. There is a lot of interest in this capability, but we need more information on these design questions so that we can decide on the answers.

Next Steps

Revise the paper to provide more information to help neutrals/undecided form an opinion on design choices and then return to Library Evolution:

• Expand discussion of design alternatives.
• Add more examples and before/after tables for design choices.
• Add section numbers.
• Fix typo in section "I don't need that and don't want to pay for it": In "object. the proposed thread::attribute object", "the" should be capitalized.

P2019R5 was added to 2024 April LEWG electronic poll paper (P3213R0)

P2019R6 Thread attributes (Corentin Jabot)

P2019R5 was forwarded to LWG for C++26 on LEWG 2024 April electronic poll (P3214R0)

LWG gave author feedback in St. Louis meeting -- paper needs updates.

P2019R7 Thread attributes (Corentin Jabot)

SG16 reviewed P2019R7 during its 2024-09-25 meeting. The following polls were taken:

• Poll 2: P2019R7: Name hint should be provided in the ordinary literal encoding.
  • Attendees: 8

    SF	F	N	A	SA
    3	1	3	1	0

  • Weak consensus in favor.
• Poll 3: P2019R7: Name hint should be provided as an NTMBS in the C locale encoding.
  • Attendees: 8

    SF	F	N	A	SA
    1	5	1	0	1

  • Consensus in favor.

These polls were intentionally contradictory. The second poll had stronger consensus, but with increased opposition and fewer strong proponents. Further discussion in SG16 is warranted.

The name hint feature collides with existing tension in the C++ standard regarding locale support in C and C++. A C++ program maintains distinct locale configuration for C and C++. Threads are a low level feature that interacts with C and C++, but the proposed interfaces are specific to C++. On Windows, thread names, when exposed in char-based interfaces, are likely to be encoded in the Windows' Active Code Page (ACP) which may indicate an encoding that does not match the current C or C++ locale. The C++ standard library would benefit from further analysis and proposals to clarify its interaction with the ordinary literal encoding, C locale encoding, C++ locale encoding, environment encoding (see std::text_encoding::environment(), POSIX locale, and Windows' ACP), and console encoding.

SG16 reviewed P2019R7 again during its 2025-01-22 meeting. The following poll was taken:

• Poll 1: P2019R7: Forward to LEWG modified to use the ordinary literal encoding for name hint.
  • Attendees: 9 (one abstention)
    SF F N A SA

    SF	F	N	A	SA
    4	3	1	0	0

  • Strong consensus in favor.

The new poll subsumes the previous polls from the 2024-09-25 SG16 meeting. There was less discussion regarding the use of the C locale and an NTMBS as polled last time. We clarified that, from the underlying platform perspective, thread names are held in an environment encoding (POSIX locale) or system encoding (UTF-16 on Windows). We discussed the approach of requiring programmers to provide names in the environment encoding (POSIX locale or Active Code Page (ACP) on Windows), but concerns were raised that, 1) there are no standard facilities to produce strings in such encodings today, and 2) using char for text encoded other than in the execution encoding (C or C++ locale) or the ordinary literal encoding is error prone, and 3) implementors are in a better position to know and handle encoding matters. We noted that use of the ordinary literal encoding does setup implementations for potential ODR-like concerns in the implementation of name_hint() (which might have to transcode to a platform dependent encoding) when a program consists of translation units that don't all use the same ordinary literal encoding, but concluded such scenarios are (currently) outside the scope of the standard. The choice of the ordinary literal encoding is at least partially motivated by the observation that thread names are very likely to be provided as string literals. Implementations should consult std::text_encoding::literal() as part of determining transcoding requirements.

2025-02-13 Library Evolution Hagenberg Meeting

P2019R7 Thread attributes

P2019R7:

2025-02-13 Library Evolution Hagenberg Minutes

Champion: Corentin Jabot
Chair: Inbal Levi / Eddie Nolan
Minute Taker: Andreas

Summary

POLL: Approve the change as suggested by SG16 and send D2019R8 back to LWG for C++26

Attendance: 31 (IP) + 10 (R)
Author's Position: SF
Outcome: Consensus in favor

Next Steps

Approve changes asked by SG16 and send back to LWG.

P2019R8 Thread attributes (Corentin Jabot)