Let's go ahead and meet tomorrow at 8:00 PDT/11:00 EDT as scheduled to
discuss progress, and possibly questions about malloc/new.

Join with Google Meet
meet.google.com/sbj-cvgh-vnd
Join by phone
‪(US) +1 208-925-0196‬ PIN: ‪255 542‬#

On Tue, Aug 25, 2020 at 6:28 PM Hans Boehm <boehm_at_[hidden]> wrote:

> Attendees:
> Hans Boehm
> Bronek Kozicki
> Victor Luchangco
> Jens Maurer
> Michael Scott
> Mike Spear
> Michael Wong
>
> We discussed feedback from EWG
>
> The initial discussion was about alternate keywords or
> context-sensitive-keywords to replace the current ambiguous atomic {}
> syntax.
>
> Bronek reminded us of the difficulty with "do atomic {":
>
> do do atomic { ... } while (...) is legal and hard to parse.
>
> Explained that even a relatively obscure new keyword like tm_atomic was
> likely to cause problems with existing codebases.
>
> There was lukewarm consensus (ambivalence?) on atomic do.
>
> Jens summarized EWG discussion and explained why constexpr is not a good
> indicator of transaction-safety. We increasingly have constexpr functions
> that test for a constexpr constant and execute different, possibly
> non-transaction-safe, code in other cases.
>
> Talked about what we really needed to be transaction-safe.
>
> memcpy, memset should be.
>
> STL containers are the problem.
>
> For something like vector, it's possible to get a pointer to a C array
> outside the transaction. But that fails if multiple containers are
> accessed, with one referring to the other.
>
> Traits are OK. Numeric limits, too. Constexpr values in general. What's
> the best way to characterize purely compile-time expressions?
>
> For something like std::vector, should we be limited to accessors? Can we
> grow containers inside transactions? Should malloc/new be supported?
>
> General initial reaction: Should not be required.
>
> Mike Spear argues for malloc/new. Easily supported for HTM and global
> lock. For STM, not that much more work is required.
>
> What about throwing OOM? Currently no throws in transactions are allowed,
> even non-escaping ones.
>
> Action Items:
> Jens will generate new revision with minimal guaranteed standard library
> support.
> Mike Spear will try to write up a short paper describing why malloc
> support is easy.
>
> Next meeting scheduled for 8:00 PDT, Sept. 22
>