Init and Thread-safety Information

Before working with the library, it must be initialized using nc_client_init() or nc_server_init(). Based on how the library was compiled, also libssh and/or libssh/_libcrypto_ are initialized (for multi-threaded use) too. To prevent any reachable memory at the end of your application, there are complementary destroy functions (nc_server_destroy() and nc_client_destroy() available. If your application is multi-threaded, call the destroy functions in the main thread, after all the other threads have ended. In every other thread you should call nc_thread_destroy() just before it exits.

If libnetconf2 is used in accordance with this information, there should not be memory leaks of any kind at program exit. For thread-safety details of libssh, libssl, and libcrypto, please refer to the corresponding project documentation. libnetconf2 thread-safety information is below.

## Client

Optionally, a client can specify two alternative ways to get schemas needed when connecting with a server. The primary way is to read local files in searchpath (and its subdirectories) specified via nc_client_set_schema_searchpath(). Alternatively, libnetconf2 can use callback provided via nc_client_set_schema_callback(). If these ways do not succeed and the server implements NETCONF <get-schema> operation, the schema is retrieved from the server and stored localy into the searchpath (if specified) for a future use. If none of these methods succeed to load particular schema, the data from this schema are ignored during the communication with the server.

Besides the mentioned setters, there are many other SSH, TLS and Call Home getter/setter functions to manipulate with various settings. All these settings are internally placed in a thread-specific context so they are independent and initialized to the default values within each new thread. However, the context can be shared among the threads using nc_client_get_thread_context() and nc_client_set_thread_context() functions. In such a case, be careful and avoid concurrent execution of the mentioned setters/getters and functions creating connection (no matter if it is a standard NETCONF connection or Call Home).

In the client, it is thread-safe to work with distinguish NETCONF sessions since the client settings are thread-specific as described above.

## Server

Server is FULLY thread-safe meaning you can set all the (thread-shared in contrast to client) options simultaneously while listening for or accepting new sessions or polling the existing ones. It is even safe to poll one session in several pollsession structures or one pollsession structure in several threads. Generally, servers can use more threads without any problems as long as they keep their workflow sane (behavior such as freeing sessions only after no thread uses them or similar).

## Functions List

Available in nc_client.h.

- nc_client_init()
- nc_client_destroy()
- nc_client_set_schema_searchpath()
- nc_client_get_schema_searchpath()
- nc_client_set_schema_callback()
- nc_client_get_schema_callback()
- nc_client_set_thread_context()
- nc_client_get_thread_context()

Available in nc_server.h.

- nc_server_init()
- nc_server_destroy()

Available in both nc_client.h and nc_server.h.

- nc_thread_destroy()