You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have a nice way to do inline AIOs for structs -- this API is more efficient because it avoids touching the allocator, and reduces the number of things we have to check for. (Initialization cannot fail.)
This inline API is not available for applications because it's a risk for binary compatibility -- if the AIO struct changes, then the application will need to be recompiled.
Still, this offers such a significant benefit to applications that I think it's worth enabling them to do this, provided that they opt-in to the safety considerations.
Basically, we'd expose the aio (at least size and alignment if not actual names) struct in a new header (maybe nng_unsafe.h) or possibly only exposed with a feature test macro (NNG_UNSAFE_API), along with functions to initialize and finalize it. Something like this:
We have a nice way to do inline AIOs for structs -- this API is more efficient because it avoids touching the allocator, and reduces the number of things we have to check for. (Initialization cannot fail.)
This inline API is not available for applications because it's a risk for binary compatibility -- if the AIO struct changes, then the application will need to be recompiled.
Still, this offers such a significant benefit to applications that I think it's worth enabling them to do this, provided that they opt-in to the safety considerations.
Basically, we'd expose the aio (at least size and alignment if not actual names) struct in a new header (maybe
nng_unsafe.h
) or possibly only exposed with a feature test macro (NNG_UNSAFE_API), along with functions to initialize and finalize it. Something like this:The documentation would need to make very clear the risks of embedding this in structures.
The text was updated successfully, but these errors were encountered: