wt/libuev
1
0
Fork 0
mirror of https://github.com/troglobit/libuev.git synced 2026-10-02 13:52:35 +07:00
Code Issues Packages Projects Releases Wiki Activity

Move background to a separate motivation document

Browse Source 
Signed-off-by: Joachim Nilsson <troglobit@gmail.com>
This commit is contained in:
Joachim Nilsson
2017-09-19 08:29:43 +02:00
parent 543b49fb08
commit 03ea12a41c
2 changed files with 31 additions and 33 deletions
Download Patch File Download Diff File Expand all files Collapse all files
MOTIVATION.md
+30
View File
@@ -0,0 +1,30 @@
Motivation
----------
> “Why an event loop, why not use threads?”
With the advent of light-weight processes (threads) programmers these
days have a [golden hammer](http://c2.com/cgi/wiki?GoldenHammer) they
often swing without consideration. Event loops and non-blocking I/O is
often a far easier approach, as well as less error prone.
The purpose of many applications is, with a little logic sprinkled on
top, to act on network packets entering an interface, timeouts expiring,
mouse clicks, or other types of events. Such applications are often
very well suited to use an event loop.
Applications that need to churn massively parallel algorithms are more
suitable for running multiple (independent) threads on several CPU
cores. However, threaded applications must deal with the side effects
of concurrency, like race conditions, deadlocks, live locks, etc.
Writing error free threaded applications is hard, debugging them can be
even harder.
Sometimes the combination of multiple threads *and* an event loop per
thread can be the best approach, but each application of course needs to
be broken down individually to find the most optimal approach. Do keep
in mind, however, that not all systems your application will run on have
multiple CPU cores -- some small embedded systems still use a single CPU
core, even though they run Linux, with multiple threads a program may
actually run slower! Always profile your program, and if possible, test
it on different architectures.
README.md
+1 -33
View File
@@ -12,7 +12,7 @@ libuEv | Simple event loop for Linux
* [Using -luev](src/README.md#using--luev)
* [Joystick Example](src/README.md#joystick-example)
* [Build & Install](#build--install)
* [Background](#background)
* [Motivation](MOTIVATION.md#background)
* [Origin & References](#origin--references)
@@ -59,38 +59,6 @@ examples, use the `--enable-examples` switch to the `configure` script.
The resulting .so file is ~14 kiB (<kbd>make install-strip</kbd>).
Background
----------
> “Why an event loop, why not use threads?”
With the advent of light-weight processes (threads) programmers these
days have a [golden hammer](http://c2.com/cgi/wiki?GoldenHammer) they
often swing without consideration. Event loops and non-blocking I/O is
often a far easier approach, as well as less error prone.
The purpose of many applications is, with a little logic sprinkled on
top, to act on network packets entering an interface, timeouts expiring,
mouse clicks, or other types of events. Such applications are often
very well suited to use an event loop.
Applications that need to churn massively parallel algorithms are more
suitable for running multiple (independent) threads on several CPU
cores. However, threaded applications must deal with the side effects
of concurrency, like race conditions, deadlocks, live locks, etc.
Writing error free threaded applications is hard, debugging them can be
even harder.
Sometimes the combination of multiple threads *and* an event loop per
thread can be the best approach, but each application of course needs to
be broken down individually to find the most optimal approach. Do keep
in mind, however, that not all systems your application will run on have
multiple CPU cores -- some small embedded systems still use a single CPU
core, even though they run Linux, with multiple threads a program may
actually run slower! Always profile your program, and if possible, test
it on different architectures.
Origin & References
-------------------