Content deleted Content added
Fgnievinski (talk | contribs) m →Fibers |
Rescuing 1 sources and tagging 0 as dead.) #IABot (v2.0.9.3) (Whoop whoop pull up - 12943 |
||
Line 36:
However, the use of blocking system calls in user threads (as opposed to kernel threads) can be problematic. If a user thread or a fiber performs a system call that blocks, the other user threads and fibers in the process are unable to run until the system call returns. A typical example of this problem is when performing I/O: most programs are written to perform I/O synchronously. When an I/O operation is initiated, a system call is made, and does not return until the I/O operation has been completed. In the intervening period, the entire process is "blocked" by the kernel and cannot run, which starves other user threads and fibers in the same process from executing.
A common solution to this problem (used, in particular, by many green threads implementations) is providing an I/O API that implements an interface that blocks the calling thread, rather than the entire process, by using non-blocking I/O internally, and scheduling another user thread or fiber while the I/O operation is in progress. Similar solutions can be provided for other blocking system calls. Alternatively, the program can be written to avoid the use of synchronous I/O or other blocking system calls (in particular, using non-blocking I/O, including lambda continuations and/or async/[[await]] primitives<ref>{{Cite AV media |first=Sergey |last=Ignatchenko |title=Eight Ways to Handle Non-blocking Returns in Message-passing Programs: from C++98 via C++11 to C++20 |url=https://www.youtube.com/watch?v=6lXUrvlMXNU |url-status=
===Fibers===
| |||