preshing

The biggest advantage I find with runtime reflection it that it's possible to load and manipulate data that has no C++ definition at all. This is actually handy when working with 3D geometry consumed by a GPU.

Perhaps, but it's easily overlooked because every project that needs runtime reflection badly enough has already rolled their own. (Some game engines have multiple reflection systems, eg. shader parameters vs. serialization.) This framework takes a particular approach and makes it an (almost) standalone component.

This might come true some day, but it seems not in C++20 and in recent static reflection proposals there was no way to distinguish reflected from non-reflected members in the same class.

It's the latter: A standalone framework that can be used by other projects. It's like a library (or suite of libraries) with separate modules for platform abstraction, containers, JSON, etc. A bit more "batteries included" than vanilla C++, and you only link with what you use. These modules are organized into a workspace that helps set up new build pipelines, to compensate for the lack of a standard build system in C++.

OK, I tweaked it a little bit.

Threads are not required to call QSBR::update at the same time. They can call it anytime, but they do need to call it.

I think you might be right. Maybe I should edit the post and not call it "more scalable", since I only have six cores to test on. But if it does top out at a higher core count, there are several ways it could be optimized.

Either way, Junction is BSD-licensed while TBB is GPL/$, so I hope it'll find a use somewhere.

> you've moved the fast path of the semaphore implementation into user space.

I see now why your original comment was a bit inflammatory. I should have been more clear in the post that by "lightweight", I meant exactly that: "fast path in user space". I guess not everyone shares this vocabulary. I'll improve the post.

You're right that this lightweight mutex is a semaphore, of course. But not every semaphore is a lightweight mutex. So the technique isn't pointless.

All the more reason to do our best to organize and share correct information about it.

> It may just be poor wording, but I don't think this sentence makes sense

I can see how you could might have interpreted that sentence differently. I just tweaked it a little in the post, mainly changing "the sample" to "this sample". Hopefully it's precise enough for most now.

Why does it matter whether Carmack likes JavaScript? If he doesn't like it, it won't vanish in a puff of smoke.