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.)