client: protect against possible NULL deref path

[platform/upstream/libwebsockets.git] / README.coding.md

diff --git a/README.coding.md b/README.coding.md
index 6026318..f369937 100644 (file)
--- a/README.coding.md
+++ b/README.coding.md
@@ -261,8 +261,8 @@ if left `NULL`, then the "DEFAULT" set of ciphers are all possible to select.
 Async nature of client connections
 ----------------------------------
 
-When you call `lws_client_connect(..)` and get a `wsi` back, it does not
-mean your connection is active.  It just mean it started trying to connect.
+When you call `lws_client_connect_info(..)` and get a `wsi` back, it does not
+mean your connection is active.  It just means it started trying to connect.
 
 Your client connection is actually active only when you receive
 `LWS_CALLBACK_CLIENT_ESTABLISHED` for it.
@@ -316,3 +316,81 @@ static inline int
                    
 The user code can also override or subclass the file operations, to either
 wrap or replace them.  An example is shown in test server.
+
+ECDH Support
+------------
+
+ECDH Certs are now supported.  Enable the CMake option
+
+cmake .. -DLWS_SSL_SERVER_WITH_ECDH_CERT=1 
+
+**and** the info->options flag
+
+LWS_SERVER_OPTION_SSL_ECDH
+
+to build in support and select it at runtime.
+
+SMP / Multithreaded service
+---------------------------
+
+SMP support is integrated into LWS without any internal threading.  It's
+very simple to use, libwebsockets-test-server-pthread shows how to do it,
+use -j <n> argument there to control the number of service threads up to 32.
+
+Two new members are added to the info struct
+
+       unsigned int count_threads;
+       unsigned int fd_limit_per_thread;
+       
+leave them at the default 0 to get the normal singlethreaded service loop.
+
+Set count_threads to n to tell lws you will have n simultaneous service threads
+operating on the context.
+
+There is still a single listen socket on one port, no matter how many
+service threads.
+
+When a connection is made, it is accepted by the service thread with the least
+connections active to perform load balancing.
+
+The user code is responsible for spawning n threads running the service loop
+associated to a specific tsi (Thread Service Index, 0 .. n - 1).  See
+the libwebsockets-test-server-pthread for how to do.
+
+If you leave fd_limit_per_thread at 0, then the process limit of fds is shared
+between the service threads; if you process was allowed 1024 fds overall then
+each thread is limited to 1024 / n.
+
+You can set fd_limit_per_thread to a nonzero number to control this manually, eg
+the overall supported fd limit is less than the process allowance.
+
+You can control the context basic data allocation for multithreading from Cmake
+using -DLWS_MAX_SMP=, if not given it's set to 32.  The serv_buf allocation
+for the threads (currently 4096) is made at runtime only for active threads.
+
+Because lws will limit the requested number of actual threads supported
+according to LWS_MAX_SMP, there is an api lws_get_count_threads(context) to
+discover how many threads were actually allowed when the context was created.
+
+It's required to implement locking in the user code in the same way that
+libwebsockets-test-server-pthread does it, for the FD locking callbacks.
+
+There is no knowledge or dependency in lws itself about pthreads.  How the
+locking is implemented is entirely up to the user code.
+
+
+Libev / Libuv support
+---------------------
+
+You can select either or both
+
+-DLWS_WITH_LIBEV=1
+-DLWS_WITH_LIBUV=1
+
+at cmake configure-time.  The user application may use one of the
+context init options flags
+
+LWS_SERVER_OPTION_LIBEV
+LWS_SERVER_OPTION_LIBUV
+
+to indicate it will use either of the event libraries.