Re: Moving sp_thread_pause, sp_thread_sleep to Core

From: Christian Mazakas (christian.mazakas_at_[hidden])
Date: 2023-06-01 16:23:14

> Gavin Lambert via Boost
> Unordered's concurrent flat map
>
> Which is where, exactly?  It does not appear to currently exist in the
> library as far as I can tell, not even in develop...

I apologize for forgetting this.

It lives here: https://github.com/boostorg/unordered/tree/feature/cfoa

There's also an open PR for this, if you'd like to offer some code review:
https://github.com/boostorg/unordered/pull/188

> Andrey Semashev via Boost
> There is a better implementation in Boost.Atomic:

Well, I'm always up for that!

> I would rather have those, along with a spin_mutex implementation, in
> Boost.Thread, but I realize Peter wouldn't want to depend on it in
> Boost.SmartPtr.

I wouldn't like this either. Right now, SmartPtr is a header-only library and
adding a dependency on Thread introduces a binary dependency which means
`./vcpkg install boost-smart-ptr` now creates the `libboost_thread.a`.

This applies similarly for Unordered as well. I'd prefer to avoid
having a binary
dependency _just_ for a small header-only component.

> That everyone depends on Core doesn't mean we should pile everything in it.

I agree with this, which is why I figured I'd ask the mailing list. Do
enough other
Boost developers agree that these primitives are universal enough such that
they should be in Core?

If not, that's fine. There's always vendoring. After all, a little
copy-paste is better than
a little dependency or sayeth the great Rob Pike.

But purporting that we agree they should be somewhere in Boost (and
not in a detail header),
where should they live?

- Christian