Shared memory synchronization primitives

[bavshin-f5]

To enable use of shared memory in the modules, we need a set of safe abstractions over src/os/unix/ngx_atomic.h, src/core/ngx_shmtx.h, src/core/ngx_slab.h and src/core/ngx_rwlock.h.

The goal is both to offer good safe Rust types and to be interoperable with the existing C types (upstream peers might be the most important here). It is acceptable if these goals lead to a two distinct sets of types.

Some inspiration could be taken from the Rust for Linux project and the Rust Atomics and Locks book.

[u5surf]

@bavshin-f5

I'm a collaborator of nginx-module-vts which is collecting and viewing the virtual host’s traffic status with shared memory. We have a plan to rewrite more improved developer experience. One of the plan, we rewrite the module with ngx-rust to respect a memory safety, to be more intuitive to develop a new feature, and to make it easier to write some unit tests than conventional C’s module.

Unfortunately, we knew the issue it is not supported shared memory on this library, it could not start to rewrite with this. However, we would like to tried to work on this issue with your co-operation to be a rewritable our module with this. Could you tell us what can we do about this library?

[bavshin-f5]

Greetings,

That's an interesting coincidence. Past couple of weeks I've been working on preparing the shared zone support code from an internal project for publishing. Hopefully, I'll get the pull-request ready this week.

The initial plan is to add:

• Abstractions for shared zone initialization.
• allocator_api2::alloc::Allocator implementations over ngx_slab_pool_t and ngx_pool_t.
• A couple of Allocator-based collections based on the nginx core types: byte strings, ngx_rbtree_t and ngx_queue_t. Vec is already implemented in allocator-api2.
• RwLock and Mutex implemented as a port of the nginx locking code over the Rust atomics. These types unfortunately won't be interoperable with ngx_atomic_t, so no proper access to the nginx internal shared zones yet.
• Reference-counted pointer wrapper compatible with shared memory (similar to std::sync::Arc)

A good starting point for you would be to determine the data layout for your shared memory and see what additional types and data structures you will need. We can discuss these requirements when I publish the initial support.

---

One thing you've mentioned is a better support for unit-tests. This scenario isn't well supported right now; most of the code from ngx-rust ends up calling the nginx-sys ffi bindings and requires loading symbols from the nginx binary. There's a plan to address that and even a possible solution, but unit-test support has lower priority than lots of other WIP stuff :(

[bavshin-f5]

Review for the initial shared memory interfaces is in progress in https://github.com/nginx/ngx-rust/pull/164, feel free to check the API and the examples.