1a93e73402
Currently we always reserve a fakewsi per pt so events that don't have a related actual wsi, like vhost-protocol-init or vhost cert init via protocol callback can make callbacks that look reasonable to user protocol handler code expecting a valid wsi every time. This patch splits out stuff that user callbacks often unconditionally expect to be in a wsi, like context pointer, vhost pointer etc into a substructure, which is composed into struct lws at the top of it. Internal references (struct lws is opaque, so there are only internal references) are all updated to go via the substructre, the compiler should make that a NOP. Helpers are added when fakewsi is used and referenced. If not PLAT_FREERTOS, we continue to provide a full fakewsi in the pt as before, although the helpers improve consistency by zeroing down the substructure. There is a huge amount of user code out there over the last 10 years that did not always have the minimal examples to follow, some of it does some unexpected things. If it is PLAT_FREERTOS, that is a newer thing in lws and users have the benefit of being able to follow the minimal examples' approach. For PLAT_FREERTOS we don't reserve the fakewsi in the pt any more, saving around 800 bytes. The helpers then create a struct lws_a (the substructure) on the stack, zero it down (but it is only like 4 pointers) and prepare it with whatever we know like the context. Then we cast it to a struct lws * and use it in the user protocol handler call. In this case, the remainder of the struct lws is undefined. However the amount of old protocol handlers that might touch things outside of the substructure in PLAT_FREERTOS is very limited compared to legacy lws user code and the saving is significant on constrained devices. User handlers should not be touching everything in a wsi every time anyway, there are several cases where there is no valid wsi to do the call with. Dereference of things outside the substructure should only happen when the callback reason shows there is a valid wsi bound to the activity (as in all the minimal examples). |
||
|---|---|---|
| .. | ||
| async-dns | ||
| dhcpclient | ||
| ntpclient | ||
| smd | ||
| CMakeLists.txt | ||
| README.md | ||
| system.c | ||
LWS System Helpers
Lws now has a little collection of helper utilities for common network-based functions necessary for normal device operation, eg, async DNS, ntpclient (necessary for tls validation), and DHCP client.
Conventions
If any system helper is enabled for build, lws creates an additional vhost
"system" at Context Creation time. Wsi that are created for the system
features are bound to this. In the context object, this is available as
.vhost_system.
Attaching to an existing context from other threads
To simplify the case different pieces of code want to attach to a single lws_context at runtime, from different thread contexts, lws_system has an api via an lws_system operation function pointer where the other threads can use platform-specific locking to request callbacks to their own code from the lws event loop thread context safely.
For convenience, the callback can be delayed until the system has entered or passed a specified system state, eg, LWS_SYSTATE_OPERATIONAL so the code will only get called back after the network, ntpclient and auth have been done. Additionally an opaque pointer can be passed to the callback when it is called from the lws event loop context.
Implementing the system-specific locking
lws_system_ops_t struct has a member .attach
int (*attach)(struct lws_context *context, int tsi, lws_attach_cb_t *cb,
lws_system_states_t state, void *opaque,
struct lws_attach_item **get);
This should be defined in user code as setting locking, then passing the arguments through to a non-threadsafe helper
int
__lws_system_attach(struct lws_context *context, int tsi, lws_attach_cb_t *cb,
lws_system_states_t state, void *opaque,
struct lws_attach_item **get);
that does the actual attach work. When it returns, the locking should be unlocked and the return passed back.
Attaching the callback request
User code should call the lws_system_ops_t .attach function like
lws_system_get_ops(context)->attach(...);
The callback function which will be called from the lws event loop context should look like this
void my_callback(struct lws_context *context, int tsi, void *opaque);
with the callback function name passed into the (*attach)() call above. When the callback happens, the opaque user pointer set at the (*attach)() call is passed back to it as an argument.