A couple of comments that occurred to me after the fact:

1. Looking at the specification of synchronized_pool_resource (which I
think is what we were talking about), I think it's
synchronization characteristics are underspecified. But if they were fully
and correctly specified then it should probably not be usable inside
transactions. Alternatively, it could perhaps get malloc-like treatment,
but that seems overkill for something I haven't yet seen used.

2. We unfortunately didn't get around to shared_ptr/weak_ptr.
Reference counts can be observed with either use_count() or weak_ptr, so I
think they have to be excluded. Are there any other library facilities that
need to be excluded because they use shared_ptr or the like internally?
Std::future presumably doesn't count because it's already excluded?

Hans

On Tue, Mar 9, 2021 at 1:57 PM Hans Boehm <boehm_at_[hidden]> wrote:

> Attendees: Hans Boehm, Victor Luchangco, Jens Maurer, Michael Scott, Mike
> Spear
>
> We discussed the state of P1875 and P2066, trying to ascertain whether
> things are in sufficiently consistent shape.
>
> What's the role of the "inline function with reachable definition"
> restriction?
>
> The position at the end of the last meeting was essentially that we
> preserve this for unknown user functions, but generally require most of the
> standard library to be supported, even if the implementation violates this
> constraint.
>
> There is clearly a tension here: Once we support various library calls
> that require fallback to a global lock when they do difficult things, why
> don't we just require the compiler to do the same?
>
> What about std::function, which can essentially replace function pointers?
>
> In the end, we decided to stick to this for now: We don't require the
> compiler to implement a fallback, but the standard library code may have
> to. This will clearly be revisited again. It should avoid the need for more
> than syntax-level compiler support for an HTM-based implementation.
>
> Other library functions that should probably be disallowed because they
> involve visible synchronization:
> synchronized_pool_resource, signal(), Handler functions (e.g. terminate),
> time zones?
>
> Other library functions that relate to function pointers like
> std::function and std::bind should be allowed.
>
> Action Items:
>
> Jens to update and submit P2066
>
> Hans to update P1875, if needed.
>
> Next meeting: Tuesday April 6, 8am PDT / 11:00am EDT
>
> meet.google.com/sbj-cvgh-vnd
>
> +1 208-925-0196‬ PIN: ‪255 542‬#
>
>
>