Process/scheduler fails to compile when using std::pmr::polymorphic_allocator

[coldcola233]

EnTT version: 3.16.0

#include <entt/entt.hpp>
#include <memory_resource>

template<class Delta, class Allocator>
struct MyProcess : entt::basic_process<Delta, Allocator> {
    using process_type = entt::basic_process<Delta, Allocator>;
    using allocator_type = typename process_type::allocator_type;
    using delta_type   = typename process_type::delta_type;

    MyProcess(const allocator_type &alloc, delta_type delay)
        : process_type{alloc}, remaining{delay} {}

    void update(delta_type d, void*) override {
        remaining -= d;
        if (remaining <= delta_type{0}) this->succeed();
    }
private:
    delta_type remaining;
};

using Sched = entt::basic_scheduler<float, std::pmr::polymorphic_allocator<void>>;
using Proc  = MyProcess<float, std::pmr::polymorphic_allocator<void>>;

int main() {
    std::pmr::unsynchronized_pool_resource pool;
    std::pmr::polymorphic_allocator<void> alloc{&pool};
    Sched sched{alloc};
    sched.attach<Proc>(1.0f);   // <-- error here
}

The method attach is implemented as:

    template<typename Type, typename... Args>
    type &attach(Args &&...args) {
        const auto &allocator = handlers.second();
        return *handlers.first().emplace_back(std::allocate_shared<Type>(allocator, allocator, std::forward<Args>(args)...));
    }

MyProcess satisfies std::uses_allocator_v, so std::allocate_shared will attempt to propagate std::pmr::polymorphic_allocator<void>.
But it failed.

[skypjack]

Hello, sorry for the late reply.

But it failed.

Can you elaborate on this, perhaps explaining the error you're getting or something similar?
Also, does it work with previous versions of EnTT? Not sure about it from your description.

[coldcola233]

Sorry. I'm no good at Englist and did not carefully check my description. So my description looks strange.
It probably won't be compatible with the old version; the update mentions that process has been redesigned.

Look at "entt/process/process.hpp" in line 224.

return *(next.first() = std::allocate_shared<Type>(allocator, allocator, std::forward<Args>(args)...));

The std::allocate_shared try to spread allocator, but it failed.
For example:

std::allocate_shared<Type>(allocator1, allocator2, std::forward<Args>(args)...))

If the Type meet std::uses_allocator_v<Type, AllocType> == true, so use std::pmr::polymorphic_allocator will cause Type construct with arguments (allocator1, allocator2, args...).

Pass parameter allocator1 will be automatically handled by std::allocator_shared.
The allocator parameter was passed repeatedly, and caused compile error.

The std::allocate_shared doesn't seem to try to spread std::allocator. So when using std::allocator, it work normally.

[skypjack]

I have no idea why this happens, nor how much of it has to do with EnTT, but I'll look into it. Thanks for bringing it up. 👍
For now I'm leaving it in triage, because I really don't know if there's anything I can do about it or what else.

[coldcola233]

Sorry, I forgot about this issue earlier.

I have been studying it recently. I finally figured out the reason.

First quote examples similar to those in a docx.

template<class Delta, class Allocator>
struct MyProcess : entt::basic_process<Delta, Allocator> {
    using process_type   = entt::basic_process<Delta, Allocator>;
    using allocator_type = typename process_type::allocator_type;
    using delta_type     = typename process_type::delta_type;

    MyProcess(const allocator_type &alloc ,delta_type delay)
        : process_type{alloc}, remaining{delay} {
    }


    void update(delta_type d, void *) override {
        remaining -= d;
        if (remaining <= delta_type{0}) {
            this->succeed();
        }
    }

private:
    delta_type remaining;
};

using SchedPmr = entt::basic_scheduler<float, std::pmr::polymorphic_allocator<void>>;
using ProcPmr  = MyProcess<float, std::pmr::polymorphic_allocator<void>>;

// A part of EnTT's source code

template<typename Type, typename... Args>
type &attach(Args &&...args) {
    const auto &allocator = handlers.second();
    return *handlers.first().emplace_back(std::allocate_shared<Type>(allocator, allocator, std::forward<Args>(args)...));
}

std::allocator<void> alloc{};
Sched sched;
constexpr auto b1 = std::uses_allocator_v<Proc, std::allocator<void>>; // equals to true

// So in the EnTT, the parameters are roughly passed like this
// ok
std::ignore = std::allocate_shared<Proc>( 
    std::allocator<void>{}, // Manual transmission
    std::allocator<void>{}, // Manual transmission
    1.0f
);

Why does this appear to work with std::allocator on MSVC? Looking at MSVC STL (19.51):

struct _Default_allocator_traits { // traits for std::allocator

// ...

template <class _Objty, class... _Types>
static _CONSTEXPR20 void construct(_Alloc&, _Objty* const _Ptr, _Types&&... _Args) {
#if _HAS_CXX20
    _STD construct_at(_Ptr, _STD forward<_Types>(_Args)...);
#else // ^^^ _HAS_CXX20 / !_HAS_CXX20 vvv
    ::new (const_cast<void*>(static_cast<const volatile void*>(_Ptr))) _Objty(_STD forward<_Types>(_Args)...);
#endif // ^^^ !_HAS_CXX20 ^^^
}
};
//...

On MSVC STL, std::allocator follows a different code path in MSVC STL because it is handled by _Default_allocator_traits, whose construct implementation directly calls std::construct_at and therefore does not perform allocator-aware construction.
On the other hand, std::pmr::polymorphic_allocator and most user-defined allocators are handled by _Normal_allocator_traits.

struct _Normal_allocator_traits {

// ...

template <class _Ty, class... _Types>
static _CONSTEXPR20 void construct(_Alloc& _Al, _Ty* _Ptr, _Types&&... _Args) {
    if constexpr (_Uses_default_construct<_Alloc, _Ty*, _Types...>::value) {
#if _HAS_CXX20
        _STD construct_at(_Ptr, _STD forward<_Types>(_Args)...);
#else // ^^^ _HAS_CXX20 / !_HAS_CXX20 vvv
        ::new (static_cast<void*>(_Ptr)) _Ty(_STD forward<_Types>(_Args)...);
#endif // ^^^ !_HAS_CXX20 ^^^
    } else {
        _Al.construct(_Ptr, _STD forward<_Types>(_Args)...);
    }
}

// ...

}

std::pmr::polymorphic_allocator overloaded method construct(...)

template <class _Uty, class... _Types>
    void construct(_Uty* const _Ptr, _Types&&... _Args) {
        // propagate allocator *this if uses_allocator_v<remove_cv_t<_Uty>, polymorphic_allocator>
#if _HAS_CXX20
        // equivalent to calling uninitialized_construct_using_allocator except for handling of cv-qualification
        _STD apply(
            [_Ptr](auto&&... _Construct_args) {
                return ::new (const_cast<void*>(static_cast<const volatile void*>(_Ptr)))
                    _Uty(_STD forward<decltype(_Construct_args)>(_Construct_args)...);
            },
            _STD uses_allocator_construction_args<_Uty>(*this, _STD forward<_Types>(_Args)...));  // <------ here 
#else // ^^^ _HAS_CXX20 / !_HAS_CXX20 vvv
        allocator<char> _Al{};
        if constexpr (_Is_cv_pair<_Uty>) {
            _STD _Uses_alloc_construct_pair(_Ptr, _Al, *this, _STD forward<_Types>(_Args)...);
        } else {
            _STD _Uses_alloc_construct_non_pair(_Ptr, _Al, *this, _STD forward<_Types>(_Args)...);
        }
#endif // ^^^ !_HAS_CXX20 ^^^
    }

Therefore, std::pmr::polymorphic_allocator performs allocator-aware construction through its construct member function.

entt::basic_process defines an allocator_type alias, which causes std::uses_allocator_v<MyProcess<float, Alloc>, Alloc> to evaluate to true. This is sufficient for allocator-aware construction to become eligible.

When a PMR allocator is used, allocator-aware construction is triggered.

During construction, the implementation first attempts to match a constructor of the form:

(std::allocator_arg_t, const Alloc&, Args...)

which does not match in this example.

It then attempts the trailing-allocator form:

(Args..., const Alloc&)

In this case, Args... becomes:

[Alloc, float]

because basic_scheduler::attach already passes an allocator explicitly:

std::allocate_shared<Type>(allocator, allocator, std::forward<Args>(args)...)

As a result, the allocator-aware construction machinery effectively tries to construct:

Type(Alloc, float, const Alloc&)

where the final const Alloc& is automatically injected by std::uses_allocator_construction_args.

Construction then fails because the allocator is supplied twice, producing a constructor signature that does not exist.

In other words, the allocator is effectively supplied twice:

1. Explicitly by basic_scheduler::attach:

    std::allocate_shared<Type>(
        allocator,
        allocator,
        std::forward<Args>(args)...);

2. Implicitly by allocator-aware construction through
   std::uses_allocator_construction_args.

This issue is usually hidden when using std::allocator on MSVC because the relevant allocator-aware construction path is not exercised. However, allocators that participate in allocator-aware construction, such as std::pmr::polymorphic_allocator, expose the issue by injecting an additional allocator argument through std::uses_allocator_construction_args.

[skypjack]

Thanks for the detailed explanation @coldcola233 do you also have a minimal solution suggested for this, something you've already tried locally and can confirm works? From what you've said, I think I can guess what needs to be done, but I'm curious if you've tried it yet.

[coldcola233]

Yes, I tried a local fix and it resolves the issue.

The change is fairly small, although I currently consider it a breaking change.

The idea is to stop passing the allocator explicitly through attach:

template<typename Type, typename... Args>
type &attach(Args &&...args) {
    const auto &allocator = handlers.second();
    return *handlers.first().emplace_back(
        std::allocate_shared<Type>(allocator, std::forward<Args>(args)...)
    );
}

and instead make derived processes support construction both with and without an allocator, for example:

MyProcess(delta_type delay, const allocator_type &alloc = {}) // `alloc` as the last parameter
    : process_type{alloc},
      remaining{delay} {}

(or equivalently by providing separate allocator and non-allocator overloads).

With this approach, the allocator becomes part of the process construction contract, instead of being implicitly injected through attach, which is where the current design seems to lose consistency.

I've tested this locally and it resolves the issue. However, existing process types that currently expect the allocator to be forwarded as a regular constructor argument would need to be adjusted, which is why I consider it a breaking change.

One caveat is that stateful allocators may need to participate in construction explicitly. Custom stateful allocators may need to provide an appropriate construct overload (or otherwise support allocator-aware construction) so that the process instance can receive the allocator used by allocate_shared.

This would probably need to be documented if such an approach is adopted.