Date: Mon, 31 May 2021 16:59:14 -0700
Let's cancel the SG5 meeting tomorrow.
The only issue that has come up is that LEWG would like us to present on
August 17.
We will need a minor P2066 revision that briefly summarizes existing
decisions. I can draft the additional text, and ask Jens to incorporate it.
I don't think this requires group discussion.
My list of such decisions, copied from another thread:
1) Language, not library facility. Detailed discussion in P1875. (Like the
current TS. The lambda-based alternative was not well-liked, and has issues
with varargs access. The RAII variant raises weird semantics issues with
transactions in the heap that nobody wanted to deal with.)
2) Leave a lot implementation-defined for the TS, to support
experimentation. Focus on HTM or trivial global lock support, but allow
more elaborate implementations. (Unlike the current TS.)
3) No support for explicitly declaring transaction-safety. (Unlike the
current TS; major simplification.)
4) No escaping exceptions. (Unlike the current TS; major simplification.)
5) The "atomic do {...}" syntax. (Non-unanimous consensus in EWG. No better
ideas. Mostly making it work without adding a keyword.)
6) [Recent change, but has been discussed in EWG] Allow malloc (and hence
non-escaping exceptions, and much more of the standard library) inside
transactions. (Also discussed in P1875, but more as an open issue.)
I think the main, and probably only, question for LEWG is whether the new
list of facilities in 16.4.6.17 [atomic.use] is as good as we can make it
without implementation experience.
Hans
The only issue that has come up is that LEWG would like us to present on
August 17.
We will need a minor P2066 revision that briefly summarizes existing
decisions. I can draft the additional text, and ask Jens to incorporate it.
I don't think this requires group discussion.
My list of such decisions, copied from another thread:
1) Language, not library facility. Detailed discussion in P1875. (Like the
current TS. The lambda-based alternative was not well-liked, and has issues
with varargs access. The RAII variant raises weird semantics issues with
transactions in the heap that nobody wanted to deal with.)
2) Leave a lot implementation-defined for the TS, to support
experimentation. Focus on HTM or trivial global lock support, but allow
more elaborate implementations. (Unlike the current TS.)
3) No support for explicitly declaring transaction-safety. (Unlike the
current TS; major simplification.)
4) No escaping exceptions. (Unlike the current TS; major simplification.)
5) The "atomic do {...}" syntax. (Non-unanimous consensus in EWG. No better
ideas. Mostly making it work without adding a keyword.)
6) [Recent change, but has been discussed in EWG] Allow malloc (and hence
non-escaping exceptions, and much more of the standard library) inside
transactions. (Also discussed in P1875, but more as an open issue.)
I think the main, and probably only, question for LEWG is whether the new
list of facilities in 16.4.6.17 [atomic.use] is as good as we can make it
without implementation experience.
Hans
Received on 2021-05-31 18:59:27