Lines Matching +full:thread +full:- +full:1 +full:- +full:4 +full:- +full:posix
5 - Chrome / Chromium, transmission, tmux, ntp SNTP... [libevent](https://libevent.org/)
6 - node.js / cjdns / Julia / cmake ... [libuv](https://archive.is/64pOt)
7 …- Gstreamer, Gnome / GTK apps ... [glib](https://people.gnome.org/~desrt/glib-docs/glib-The-Main-E…
8 - SystemD ... sdevent
9 - OpenWRT ... uloop
26 - they have a **single thread**, therefore they do not require locking
27 - they are **not threadsafe**
28 - they require **nonblocking IO**
29 - they **sleep** while there are no events (aka the "event wait")
30 - if one or more event seen, they call back into user code to handle each in
33 ### They have a single thread
35 By doing everything in turn on a single thread, there can be no possibility of
36 conflicting access to resources from different threads... if the single thread
46 Event loops mandate doing everything in a single thread. You cannot call their
49 Lws apis cannot be called safely from any thread other than the event loop one,
65 An OS "wait" of some kind is used to sleep the event loop thread until something
92 - the quality is generally higher than self-rolled ones. Someone else is
94 - the event libraries are crossplatform, they will pick the most effective
98 - If your application uses a event library, it is possible to integrate very
100 That is extremely messy or downright impossible to do with hand-rolled loops.
104 - thread lifecycle has to be closely managed, threads must start and must be
108 - threads may do things sequentially or genuinely concurrently, this requires
112 - threads do not scale well to, eg, serving tens of thousands of connections;
117 The ideal situation is all your code operates via a single event loop thread.
118 For lws-only code, including lws_protocols callbacks, this is the normal state
127 ### 1) Use a common event library for both lws and application code
129 This is the best choice for Linux-class devices. If you write your application
136 libevent-capable libraries the same way, and compared to hand-rolled loops, the
152 libraries, you can find it in ./includes/libwebsockets/lws-eventlib-exports.h.
159 …nimal-http-server.c](https://libwebsockets.org/git/libwebsockets/tree/minimal-examples/http-server…
161 ### 4) Cooperate at thread level
164 single thread, it means the codebases cannot call each other's apis directly.
167 area of memory and list what they want done from the lws thread context, before
171 lws thread context.
181 while (1) {
189 - the whole thing spins at 100% CPU when idle, or
191 - the waits have timeouts where they sleep for short periods, but then the
203 Any thread you add should have a clear reason to specifically be a thread and
204 not done on the event loop, without a new thread or the consequent locking (and
211 For any IO that may wait, you must spawn an IO thread for it, purely to handle
214 thread if read() or write() has completed, but costs threads and locking to get
224 With blocked threads, the thread can do no useful work at all while it is stuck
225 waiting. With event loops the thread can service other events until something
234 - threads have an OS-side footprint both as objects and in the scheduler
236 - thread context switches are not slow on modern CPUs, but have side effects
239 - threads are designed to be blocked for arbitrary amounts of time if you use
242 when in fact your thread is almost always blocked and not doing useful work.
244 - threads require their own stack, which is on embedded is typically suffering
245 from a dedicated worst-case allocation where the headroom is usually idle
247 - locking must be handled, and missed locking or lock order bugs found
251 - Typically, at CPU speeds, nothing is happening at any given time on most
255 - The POSIX sockets layer is disjoint from the actual network device driver.
256 It means that once you hand off the packet to the networking stack, the POSIX
261 - Passing data around via POSIX apis between the user code and the networking
265 - So long as enough packets-worth of data are in the network stack ready to be
269 - The network device itself is inherently serializing packets, it can only send
273 - Many user systems are decoupled like the network stack and POSIX... the user
275 interrupt or internal thread or other process contexts