b10428163a
Currently there is no way to distinguish between a caller explicitly asking for a semaphore with a limit that happens to be `UINT_MAX` and a semaphore that just has a limit "as large as possible". Add `K_SEM_MAX_LIMIT`, currently defined to `UINT_MAX`, and akin to `K_FOREVER` versus just passing some very large wait time. In addition, the `k_sem_*` APIs were type-confused, where the internal data structure was `uint32_t`, but the APIs took and returned `unsigned int`. This changes the underlying data structure to also use `unsigned int`, as changing the APIs would be a (potentially) breaking change. These changes are backwards-compatible, but it is strongly suggested to take a quick scan for `k_sem_init` and `K_SEM_DEFINE` calls with `UINT_MAX` (or `UINT32_MAX`) and replace them with `K_SEM_MAX_LIMIT` where appropriate. Signed-off-by: James Harris <james.harris@intel.com> |
||
|---|---|---|
| .. | ||
| big_http_download | ||
| can | ||
| coap_client | ||
| coap_server | ||
| dumb_http_server | ||
| dumb_http_server_mt | ||
| echo | ||
| echo_async | ||
| echo_async_select | ||
| echo_client | ||
| echo_server | ||
| http_client | ||
| http_get | ||
| net_mgmt | ||
| packet | ||
| sntp_client | ||
| socketpair | ||
| tcp | ||
| websocket_client | ||