After experimenting and considering performance/flexibility it is has become clear that the registry should not impose any locking mechanisms on the data it provides access to. Rather, the data should be thread safe itself. In the JSON context this means we need thread safe types for boolean and numbers (atomics), strings (glz::async_string), arrays (glz::async_vector), and objects (glz::async_map).
By taking this approach we don't have to use complex chains of mutexes and can asynchronously manipulate various structures efficiently. Because the glz::async_vector and glz::async_map will store thread safe elements, these on need to lock on insertion and deleting, making asynchronous writes through complex structures feasible and extremely efficient.
After experimenting and considering performance/flexibility it is has become clear that the registry should not impose any locking mechanisms on the data it provides access to. Rather, the data should be thread safe itself. In the JSON context this means we need thread safe types for boolean and numbers (atomics), strings (
glz::async_string
), arrays (glz::async_vector
), and objects (glz::async_map
).By taking this approach we don't have to use complex chains of mutexes and can asynchronously manipulate various structures efficiently. Because the
glz::async_vector
andglz::async_map
will store thread safe elements, these on need to lock on insertion and deleting, making asynchronous writes through complex structures feasible and extremely efficient.