From 4e1ffdca6d97c1bddc460835c94b16bc64284861 Mon Sep 17 00:00:00 2001 From: mochalins <117967760+mochalins@users.noreply.github.com> Date: Fri, 23 May 2025 17:02:52 +0900 Subject: Fix typos across docs, comments, and CMake --- docs/BUILD_CROSSCOMPILE.adoc | 2 +- docs/RATIONALE.adoc | 8 ++++---- docs/man/man7.desc | 2 +- docs/ref/api/aio.md | 2 +- docs/ref/api/ctx.md | 2 +- docs/ref/api/errors.md | 2 +- docs/ref/api/http.md | 14 +++++++------- docs/ref/api/id_map.md | 4 ++-- docs/ref/api/init.md | 8 ++++---- docs/ref/api/logging.md | 4 ++-- docs/ref/api/msg.md | 2 +- docs/ref/api/sock.md | 2 +- docs/ref/api/stats.md | 6 +++--- docs/ref/api/synch.md | 4 ++-- docs/ref/api/thread.md | 2 +- docs/ref/api/time.md | 2 +- docs/ref/migrate/nng1.md | 8 ++++---- 17 files changed, 37 insertions(+), 37 deletions(-) (limited to 'docs') diff --git a/docs/BUILD_CROSSCOMPILE.adoc b/docs/BUILD_CROSSCOMPILE.adoc index ba080b3f..f454726a 100644 --- a/docs/BUILD_CROSSCOMPILE.adoc +++ b/docs/BUILD_CROSSCOMPILE.adoc @@ -4,7 +4,7 @@ endif::[] = Building for Cross Compilation -TIP: Cross-compiling is used when the operating system or process architecure +TIP: Cross-compiling is used when the operating system or process architecture the software is being built for is different than the system where the software is being compiled. If you don't know what this means, this does not apply to and you should ignore this file. diff --git a/docs/RATIONALE.adoc b/docs/RATIONALE.adoc index b278ce3f..6a1423c3 100644 --- a/docs/RATIONALE.adoc +++ b/docs/RATIONALE.adoc @@ -51,7 +51,7 @@ many of which feed into others, such that tracking flow through the state machines is incredibly painful. Worse, these state machines are designed to be run from a single worker -thread. This means that a given socket is entirely single theaded; you +thread. This means that a given socket is entirely single threaded; you could in theory have dozens, hundreds, or even thousands of connections open, but they would be serviced only by a single thread. (Admittedly non-blocking I/O is used to let the OS kernel calls run asynchronously @@ -108,7 +108,7 @@ This means that implementing new transports which might need something other than a file descriptor, is really non-trivial. This stymied my first attempt to add http://www.openssl.org[OpenSSL] support to get TLS added -- _OpenSSL_ has it's own `struct BIO` for this stuff, and I could -not see an easy way to convert _nanomsg_'s `usock` stuff to accomodate the +not see an easy way to convert _nanomsg_'s `usock` stuff to accommodate the `struct BIO`. In retrospect, _OpenSSL_ wasn't the ideal choice for an SSL/TLS library, @@ -231,7 +231,7 @@ The completion routines are _usually_ run on a separate worker thread available number of CPU cores to ensure that we never wait while a CPU core is available for work), but they can be run "synchronously" if the I/O provider knows it is safe to do so (for example the completion -is occuring in a context where no locks are held.) +is occurring in a context where no locks are held.) The `nni_aio` structures are accessible to user applications as well, which can lead to much more efficient and easier to write asynchronous applications, @@ -291,7 +291,7 @@ layer makes implementation of these all fairly straight-forward. As part of implementing a real WebSocket transport, it was necessary to implement at least some HTTP capabilities. Rather than just settle for a toy -implementation, _nng_ has a very capable HTTP server and client framework. +implementation, _nng_ has a very capable HTTP server and client framework. The server can be used to build real web services, so it becomes possible for example to serve static content, REST API, and _nng_ based services all from the same TCP port using the same program. diff --git a/docs/man/man7.desc b/docs/man/man7.desc index eae6694f..25d0ca2d 100644 --- a/docs/man/man7.desc +++ b/docs/man/man7.desc @@ -8,7 +8,7 @@ A given xref:nng_socket.5.adoc[socket] is created with exactly one protocol, and protocol defines the key behavior of the socket. (((transport))) -Conversely, transports are the underlying mechansims by which messages +Conversely, transports are the underlying mechanisms by which messages are moved between participants, such as TCP/IP or UNIX domain IPC. A given xref:nng_socket.5.adoc[socket] may be using several transports at the same time. diff --git a/docs/ref/api/aio.md b/docs/ref/api/aio.md index 2f7b9a73..b6e0ad58 100644 --- a/docs/ref/api/aio.md +++ b/docs/ref/api/aio.md @@ -197,7 +197,7 @@ void nng_aio_set_msg(nng_aio *aio, nng_msg *msg); The {{i:`nng_aio_get_msg`}} and {{i:`nng_aio_set_msg`}} functions retrieve and store a [message] in _aio_. For example, if a function to receive data is called, that function can generally be expected -to store a message on the asssociated _aio_, for the application to retrieve with +to store a message on the associated _aio_, for the application to retrieve with `nng_aio_get_msg`. Conversely an application desiring to send a message _msg_ will store it in the _aio_ using `nng_aio_set_msg`. The function implementing the send operation will retrieve the message diff --git a/docs/ref/api/ctx.md b/docs/ref/api/ctx.md index 7f18b988..bc83d6db 100644 --- a/docs/ref/api/ctx.md +++ b/docs/ref/api/ctx.md @@ -138,7 +138,7 @@ These functions (, {{i:`nng_ctx_recvmsg`}} and {{i:`nng_ctx_recv`}}) receive messages over the context _ctx_. The differences in their behaviors are as follows. > [!NOTE] -> The semantics of what receving a message means varies from protocol to +> The semantics of what receiving a message means varies from protocol to > protocol, so examination of the protocol documentation is encouraged. > Additionally, some protocols may not support receiving at all or may require other pre-conditions first. > (For example, [REQ][req] sockets cannot normally receive data until they have first sent a request.) diff --git a/docs/ref/api/errors.md b/docs/ref/api/errors.md index c7a50780..5d59d121 100644 --- a/docs/ref/api/errors.md +++ b/docs/ref/api/errors.md @@ -47,7 +47,7 @@ future locale-specific strings may be presented instead. | Error | Value | Description | | ------------------------------------------------- | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | | `NNG_EINTR` | 1 | Operation interrupted. | -| `NNG_ENOMEM` | 2 | Out of memory, or other resource exahusted. | +| `NNG_ENOMEM` | 2 | Out of memory, or other resource exhausted. | | `NNG_EINVAL` | 3 | Invalid argument. The arguments are invalid or malformed somehow. | | `NNG_EBUSY` | 4 | Resource busy. | | `NNG_ETIMEDOUT` | 5 | Timed out. The operation took longer than the allotted time. | diff --git a/docs/ref/api/http.md b/docs/ref/api/http.md index 8cb1945e..04c3ee4a 100644 --- a/docs/ref/api/http.md +++ b/docs/ref/api/http.md @@ -71,7 +71,7 @@ or [`NNG_EINVAL`] if there is some other problem with the URI. The {{i:`nni_http_get_uri`}} function is used to obtain the URI that was previously set by `nng_http_set_uri`. If the URI is unset (such as for a freshly created connection), then it returns `NULL`. The returned value -will have any query concentated, for example "/api/get_user.cgi?name=garrett". +will have any query concatenated, for example "/api/get_user.cgi?name=garrett". ### HTTP Version @@ -119,7 +119,7 @@ then a built in reason based on the _status_ will be used instead. > `nng_http_set_status`, because those functions will also set the response body to a suitable HTML document > for display to users. -Status codes are defined by the IETF. Here are defininitions that NNG provides for convenience: +Status codes are defined by the IETF. Here are definitions that NNG provides for convenience: | Name | Code | Reason Text | Notes | | ------------------------------------------------------------------------------------------------ | ---- | ------------------------------- | ----------------------------------------------------- | @@ -165,13 +165,13 @@ Status codes are defined by the IETF. Here are defininitions that NNG provides f | `NNG_HTTP_STATUS_TEAPOT` | 418 | I Am A Teapot | RFC 2324. | | `NNG_HTTP_STATUS_UNPROCESSABLE_ENTITY` | 422 | Unprocessable Entity | | `NNG_HTTP_STATUS_LOCKED` | 423 | Locked | -| `NNG_HTTP_STATUS_FAILED_DEPENDENCY` | 424 | Failed Dependency | +| `NNG_HTTP_STATUS_FAILED_DEPENDENCY` | 424 | Failed Dependency | | `NNG_HTTP_STATUS_TOO_EARLY` | 425 | Too Early | | `NNG_HTTP_STATUS_UPGRADE_REQUIRED` | 426 | Upgrade Required | | `NNG_HTTP_STATUS_PRECONDITION_REQUIRED` | 428 | Precondition Required | | | `NNG_HTTP_STATUS_TOO_MANY_REQUESTS` | 429 | Too Many Requests | | | `NNG_HTTP_STATUS_HEADERS_TOO_LARGE` | 431 | Headers Too Large | | -| `NNG_HTTP_STATUS_UNAVAIL_LEGAL_REASONS` | 451 | Unavailabe For Legal Reasons | | +| `NNG_HTTP_STATUS_UNAVAIL_LEGAL_REASONS` | 451 | Unavailable For Legal Reasons | | | `NNG_HTTP_STATUS_INTERNAL_SERVER_ERROR` | 500 | Internal Server Error | | `NNG_HTTP_STATUS_NOT_IMPLEMENTED` | 501 | Not Implemented | Server does not implement method. | | `NNG_HTTP_STATUS_BAD_GATEWAY` | 502 | Bad Gateway | @@ -406,7 +406,7 @@ Calling `nng_http_client_set_tls` invalidates any client previously obtained wit Once TLS is enabled for an `nng_http_client`, it is not possible to disable TLS. > [!NOTE] -> The TLS configuration itself cannnot be changed once it has been used to create a connection, +> The TLS configuration itself cannot be changed once it has been used to create a connection, > such as by calling [`nng_http_client_connect`], but a new one can be installed in the client. > Existing connections will use the TLS configuration that there were created with. @@ -573,7 +573,7 @@ rather than just a single element. ### Implementing a Handler ```c -typedef void (*nng_http_hander_func)(nng_http_conn *conn, void *arg, nng_aio *aio); +typedef void (*nng_http_handler_func)(nng_http_conn *conn, void *arg, nng_aio *aio); nng_err nng_http_handler_alloc(nng_http_handler **hp, const char *path, nng_http_handler_func cb); ``` @@ -674,7 +674,7 @@ void nng_http_handler_collect_body(nng_http_handler *handler, bool want, size_t ``` The {{i:`nng_http_handler_collect_body`}} function requests that HTTP server -framework collect any reuqest body for the request and attach it to the +framework collect any request body for the request and attach it to the connection before calling the callback for the _handler_. Subsequently the data can be retrieved by the handler from the request with the diff --git a/docs/ref/api/id_map.md b/docs/ref/api/id_map.md index fcbae848..b25c9e64 100644 --- a/docs/ref/api/id_map.md +++ b/docs/ref/api/id_map.md @@ -23,7 +23,7 @@ can also be randomly within the range. The identifiers are 64-bit unsigned integers and can be sparse; the structure will use space efficiently even if identifiers are very far apart. -{{footnote: The ID map is capable of storing at most 232 identifiers, even though the identifers may +{{footnote: The ID map is capable of storing at most 232 identifiers, even though the identifiers may themselves be much larger than this.}} > [!IMPORTANT] @@ -66,7 +66,7 @@ with it. > [!NOTE] > The `nng_id_map_free` frees the map itself, but will not free memory associated with -> any strctures contained within it. +> any structures contained within it. ## Store a Value diff --git a/docs/ref/api/init.md b/docs/ref/api/init.md index e26b2904..e0eedb5b 100644 --- a/docs/ref/api/init.md +++ b/docs/ref/api/init.md @@ -1,7 +1,7 @@ # Initialization & Finalization This chapter details the function used to initialize -the library before first use, and the funtion used to +the library before first use, and the function used to finalize the library and deallocate any resources used by the library. ## Initialization @@ -17,7 +17,7 @@ typedef struct { int16_t num_resolver_threads; } nng_init_params; -extern nng_err nng_init(nng_init_parms *params); +extern nng_err nng_init(nng_init_params *params); ``` Before using other interfaces in this library, it is necessary to initialize @@ -52,7 +52,7 @@ The following parameters are present: - `num_task_threads` and `max_task_threads` \ Configures the number of threads to use for tasks, which are used principally for completion callbacks. The maximum value can be used to provide an upper limit while still allowing - for a dynamically calculated value to be used, as long as it does not exceeed the maximum. + for a dynamically calculated value to be used, as long as it does not exceed the maximum. - `num_expire_threads` and `max_expire_threads` \ Configures the number of threads used for expiring operations. Using a larger value will @@ -71,7 +71,7 @@ The following parameters are present: extern void nng_fini(void); ``` -When the consumer is ready to deallocate any resoures allocated by the library, it should call +When the consumer is ready to deallocate any resources allocated by the library, it should call the {{i:`nng_fini`}} function. Each call to `nng_fini` should be paired with an earlier call to [`nng_init`]. diff --git a/docs/ref/api/logging.md b/docs/ref/api/logging.md index 75a6c356..01e63ec3 100644 --- a/docs/ref/api/logging.md +++ b/docs/ref/api/logging.md @@ -20,11 +20,11 @@ void nng_log_debug(const char *msgid, const char *msg, ...); These {{hi:`nng_log`}} functions inject a a message into the logging system, where it will be processed and potentially go to -system logs, standard output, or procssed further. +system logs, standard output, or processed further. The _msgid_ is a short prefix that should uniquely identify the message, possibly also with some kind of category. It is recommended that -strings between 8 and 16 charactes be used. As this may, but will not necessarily +strings between 8 and 16 characters be used. As this may, but will not necessarily be displayed to the user, the content of the message should not appear solely in this field. A `NULL` value is permitted here, but that may make filtering the message or other automatic processing more difficult. diff --git a/docs/ref/api/msg.md b/docs/ref/api/msg.md index 1cea98e6..5aa7ef8f 100644 --- a/docs/ref/api/msg.md +++ b/docs/ref/api/msg.md @@ -48,7 +48,7 @@ int nng_msg_dup(nng_msg **dup, nng_msg *msg); ``` The {{i:`nng_msg_dup`}} function duplicates the message _msg_, storing a pointer -to the new duplicate in _dup_. This function also returns zero on succes, or [`NNG_ENOMEM`] +to the new duplicate in _dup_. This function also returns zero on success, or [`NNG_ENOMEM`] if memory is exhausted. ## Message Size and Capacity diff --git a/docs/ref/api/sock.md b/docs/ref/api/sock.md index 4ebd8051..bc5c1380 100644 --- a/docs/ref/api/sock.md +++ b/docs/ref/api/sock.md @@ -227,7 +227,7 @@ These functions ({{i:`nng_recv`}}, {{i:`nng_recvmsg`}}, and {{i:`nng_socket_recv messages over the socket _s_. The differences in their behaviors are as follows. > [!NOTE] -> The semantics of what receving a message means varies from protocol to +> The semantics of what receiving a message means varies from protocol to > protocol, so examination of the protocol documentation is encouraged. > Additionally, some protocols may not support receiving at all or may require other pre-conditions first. > (For example, [REQ][req] sockets cannot normally receive data until they have first sent a request, diff --git a/docs/ref/api/stats.md b/docs/ref/api/stats.md index 1720f605..b2a01d8e 100644 --- a/docs/ref/api/stats.md +++ b/docs/ref/api/stats.md @@ -81,7 +81,7 @@ const nng_stat *nng_stat_find_socket(const nng_stat *stat, nng_dialer socket); ``` Sometimes it is easiest to search for a specific statistic, matching by name, -or possibly to find the tree of statistics associated iwth a specific [socket], +or possibly to find the tree of statistics associated with a specific [socket], [dialer], or [listener]. The `nng_stat_find` functions are provided for this purpose. @@ -129,7 +129,7 @@ function can be used to obtain that value. The units will be given by the value returned from [`nng_stat_unit`]. - {{i:`NNG_STAT_LEVEL`}}: - The statistic represnts a measured value which corresponds + The statistic represents a measured value which corresponds to a specific value at a specific time. For example, this may represent the number of messages currently queued for some operation, or the link speed of a network interface. Most often the absolute value is more interesting @@ -170,7 +170,7 @@ The {{i:`nng_stat_bool`}} function returns the Boolean value (either `true` or ` type [`NNG_STAT_BOOLEAN`]. If the statistics is not of this type, then it returns `false`. The {{i:`nng_stat_string`}} function returns a pointer to a string value for the statistic _stat_, -of type [`NNG_STAT_STRING`]. This string will remain valud until the snapshot that +of type [`NNG_STAT_STRING`]. This string will remain valid until the snapshot that _stat_ was collected with is deallocated with [`nng_stats_free`]. If the statistic is not of type `NNG_STAT_STRING`, then `NULL` is returned. diff --git a/docs/ref/api/synch.md b/docs/ref/api/synch.md index 62e9b7c1..ea545cab 100644 --- a/docs/ref/api/synch.md +++ b/docs/ref/api/synch.md @@ -29,7 +29,7 @@ int nng_mutx_alloc(nng_mt **mtxp); A mutex can be created by allocating one with {{i:`nng_mtx_lock`}}. On success, a pointer to the mutex is returned through _mtxp_. This function can fail due to insufficient memory or resources, in which -case it will return [`NNG_ENOMEM`]. Otherwise it will succceed and return zero. +case it will return [`NNG_ENOMEM`]. Otherwise it will succeed and return zero. ### Destroying a Mutex @@ -132,7 +132,7 @@ The difference between these functions is that one thread (which may be chosen randomly). > [!TIP] -> Use of `nng_cv_wake1` may be used to reduce the "{{i:thundering herd}}" syndrom of waking +> Use of `nng_cv_wake1` may be used to reduce the "{{i:thundering herd}}" syndrome of waking > all threads concurrently, but should only be used in circumstances where the application > does not depend on _which_ thread will be woken. When in doubt, `nng_cv_wake` is safer. diff --git a/docs/ref/api/thread.md b/docs/ref/api/thread.md index 3286f71a..20b4eea1 100644 --- a/docs/ref/api/thread.md +++ b/docs/ref/api/thread.md @@ -32,7 +32,7 @@ applications. typedef struct nng_thread nng_thread; ``` -The {{i:`nng_thread`}} structure represnts a thread, which is a single execution context. +The {{i:`nng_thread`}} structure represents a thread, which is a single execution context. A given thread will have its own stack, and CPU registers. However global state, as well as values allocated on the heap, will be shared and accessible to all threads in the system (See the [Synchronization][synchronization] chapter for functions to help with data sharing between different threads.) diff --git a/docs/ref/api/time.md b/docs/ref/api/time.md index 2855bca9..2b5ee9ba 100644 --- a/docs/ref/api/time.md +++ b/docs/ref/api/time.md @@ -12,7 +12,7 @@ typedef uint64_t nng_time; The {{i:`nng_time`}} type is used to represent a clock offset from a common base time, measured in milliseconds. -The reference, or zero value, is some arbitrary point in time, most often sytem boot, but can +The reference, or zero value, is some arbitrary point in time, most often system boot, but can be process start time or any other convenient reference. All threads within a process will use the same reference time, but be aware that different processes diff --git a/docs/ref/migrate/nng1.md b/docs/ref/migrate/nng1.md index 9e35465b..5b85c41d 100644 --- a/docs/ref/migrate/nng1.md +++ b/docs/ref/migrate/nng1.md @@ -161,7 +161,7 @@ used, and was error prone. NNG 1.x had an undocumented ability to specify the local address to bind to when dialing, by using the local address in front of the destination address separated by a semicolon. This was provided for legacy libnanomsg -compatilibility, and is no longer offered. The correct way to specify a +compatibility, and is no longer offered. The correct way to specify a local address is by setting `NNG_OPT_LOCADDR` on the dialer. ## IPC Option Type Changes @@ -274,7 +274,7 @@ Note that the new functions provide a reference to a static string, and thus do allocation, and the returned strings should not be freed. Also the IDs are provided as `uint16_t`, matching the actual wire protocol values, instead of `int`. -The `NNG_OPT_RAW` option has aso been replaced by a function, [`nng_socket_raw`]. +The `NNG_OPT_RAW` option has also been replaced by a function, [`nng_socket_raw`]. The `NNG_OPT_SENDFD` and `NNG_OPT_RECVFD` options have been replaced by [`nng_socket_get_send_poll_fd`] and [`nng_socket_get_recv_poll_fd`] respectively. @@ -284,7 +284,7 @@ Applications should keep track of this information separately. ## Subscriptions -The `NNG_OPT_SUB_SUBSCRIBE` and `NNG_OPT_SUB_UNSUBCRIBE` options have been replaced by +The `NNG_OPT_SUB_SUBSCRIBE` and `NNG_OPT_SUB_UNSUBSCRIBE` options have been replaced by the following functions: [`nng_sub0_socket_subscribe`], [`nng_sub0_socket_unsubscribe`], [`nng_sub0_ctx_subscribe`] and [`nng_sub0_ctx_unsubscribe`]. These functions, like the options they replace, are only applicable to SUB sockets. @@ -311,7 +311,7 @@ structure instead of a string. ## URL Structure Changes The details of [`nng_url`] have changed significantly, and direct -access of the structure is no longer permitted. Intead new +access of the structure is no longer permitted. Instead new accessors functions are provided: - `u_scheme` is replaced by [`nng_url_scheme`]. -- cgit v1.2.3-70-g09d2