Victor and I have both reviewed Michael and Jens' updates to the document,
in accordance with the discussion yesterday. At this point, the document
has no pending comments or TODOs. I think we are ready to share it more
broadly, though it might be good to do one more check to ensure that the
new wording about allowed operations coheres with Jens' updates to P2066.

- Mike

On Tue, Feb 9, 2021 at 2:33 PM Hans Boehm via SG5 <sg5_at_[hidden]>
wrote:

> Attendees:
>
> Hans Boehm
> Victor Luchangco
> Jens Maurer
> Michael Scott
> Michael Spear
> Michael Wong
>
> Continuation of undefined behaviour discussion for uncaught exceptions,
> this time with Jens present.
>
> We agreed that it is OK to leave exceptions escaping transactions as
> undefined behaviour, so long as we make it clear that we wish
> implementations to abort with a clear indication of what happened, but
> without invoking user replaceable code.
>
> Jens: Now that we allow malloc, should we allow invocation of
> arbitrary functions from other translation units, so long as they
> dynamically avoid IO, etc.?
>
> This turned out to be an interesting question that hadn't been fully
> considered. Initially our reaction was to allow arbitrary function calls
> and thus require implementations to provide a (probably global lock)
> fallback.
>
> Michael Scott: Really want to support an STM implementation that doesn't
> support a fallback.
>
> In the end, there was agreement on this last position, also motivated by
> concern that otherwise it's hard for the programmer to distinguish cases
> that are nominally supported, but scale too badly to be useful, from those
> that come with a reasonable expectation of scalability.
>
> We want to support those parts of the standard library that don't
> inherently violate atomicity, But we do not want to support arbitrary calls
> for which the function body is not visible to the compiler at the point of
> the call. Thus the additional changes we need for P1875 are minor.
>
> There remains consensus that we do not guarantee that use of
> transaction-unsafe code in transactions will be diagnosed by the compiler.
> What matters is dynamic use of those features, not whether they appear in
> the transaction. Transactions that do not catch bad_alloc encounter
> undefined behaviour only when they actually run out of memory.
>
> It remains TBD how to best specify the transaction-safe parts of the
> standard library, and whether we should explicitly list the included or
> excluded pieces.
>
> Next meeting:
>
> March 9, 8:00 a.m PST, 11:00 a.m. EST (Not yet Daylight time, in either US
> or Europe)
>
> meet.google.com/sbj-cvgh-vnd
>
> ‪(US) +1 208-925-0196‬ PIN: ‪255 542‬#
>
> (Other phone numbers on request.)
> --
> SG5 mailing list
> SG5_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg5
>