ne_sock_init
3

# ne_sock_init

# ne_sock_exit

perform library initialization

          #include <ne_socket.h>

            int ne_sock_init

            void ne_sock_exit

## Description

In some platforms and configurations, &neon; may be using some socket or SSL libraries which require global initialization before use. To perform this initialization, the `ne_sock_init` function must be called before any other library functions are used.

Once all use of &neon; is complete, `ne_sock_exit` can be called to perform de-initialization of socket or SSL libraries, if necessary. Uses of `ne_sock_init` and `ne_sock_exit` are "reference counted"; if N calls to `ne_sock_init` are made, only the Nth call to `ne_sock_exit` will have effect.

`ne_sock_init` will set the disposition of the `SIGPIPE` signal to ignored. No change is made to the `SIGPIPE` disposition by `ne_sock_exit`.

Both the SSL libraries supported by &neon; — OpenSSL and GnuTLS — require callbacks to be registered to allow thread-safe use of SSL. These callbacks are stored as global variables and so their state persists for as long as the library in question is loaded into the process. If multiple users of the SSL library exist within the process, this can be problematic, particularly if one is dynamically loaded (and may subsequently be unloaded).

If &neon; is configured using the `--enable-threadsafe-ssl` flag, thread-safe SSL support will be enabled automatically, as covered in the following section. Otherwise, it is not safe to use &neon; with SSL in a multi-threaded process. The function can be used to determine whether &neon; is built to enable thread-safety support in the SSL library.

### Thread-safe SSL with OpenSSL

&neon; follows two simple rules when dealing with the OpenSSL locking callbacks:

- `ne_sock_init` will set thread-safety locking callbacks if and only if no locking callbacks are already registered.

- `ne_sock_exit` will unset the thread-safety locking callbacks if and only if the locking callbacks registered are those registered by `ne_sock_init`.

Applications and libraries should be able to co-operate to ensure that SSL use is always thread-safe if similar rules are always followed.

### Thread-safe SSL with GnuTLS

The cryptography library used by GnuTLS, libgcrypt, only supports an initialization operation to register thread-safety callbacks. `ne_sock_init` will register the thread-safe locking callbacks on first use; `ne_sock_exit` cannot unregister them. If multiple users of GnuTLS are present within the process, it is unsafe to dynamically unload &neon; from the process if &neon; is configured with thread-safe SSL support enabled (since the callbacks would be left pointing at unmapped memory once &neon; is unloaded).

## Return value

`ne_sock_init` returns zero on success, or non-zero on error. If an error occurs, no further use of the &neon; library should be attempted.

## See also

,