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
There is some fairly sketchy initialization logic around nng_init, and it's possibly racy with nng_fini, and since these are done implicitly (at least nni_init is) this can lead to racy situations.
If we make this explicit, and require applications to call it up front, we can reference count calls, and be safe even with multiple consumers via a shared library, etc.
This would also allow us to eliminate nni_init() checks at run time one zillion hot paths, which also helps with code coverage, and some functions could then become no-fail (would allow changing function signatures in some cases, but having functions that cannot ever fail is good for applications.)
The text was updated successfully, but these errors were encountered:
There is some fairly sketchy initialization logic around
nng_init
, and it's possibly racy withnng_fini
, and since these are done implicitly (at leastnni_init
is) this can lead to racy situations.If we make this explicit, and require applications to call it up front, we can reference count calls, and be safe even with multiple consumers via a shared library, etc.
This would also allow us to eliminate nni_init() checks at run time one zillion hot paths, which also helps with code coverage, and some functions could then become no-fail (would allow changing function signatures in some cases, but having functions that cannot ever fail is good for applications.)
The text was updated successfully, but these errors were encountered: