3 ms·
he doesn't seem to have mentioned cooperative threads/green threads/non preemptive threads in this series http://wiki.c2.com/?CooperativeThreading http://wiki.c
by MichaelMoser123 9y ago
he doesn't seem to have mentioned cooperative threads/green threads/non preemptive threads in this series http://wiki.c2.com/?CooperativeThreading http://wiki.c2.com/?CooperativeThreading
They are easier to program than events, they still have problems like its easy to run out of a very limited stack and you have to yield your cooperative thread often to other tasks, but they are easier to maintain than a state machine (that is often done as a very big switch statement).
- Waterluvian 9y agoI'm using greenlets via gevent to handle a system that interacts with a number of http APIs, exposes an RPC API and has a data processing loop. I absolutely love the concurrency model. For cpu bound processes and short API timeouts, getting to control when my "threads" yield makes it very easy to avoid the common threading pitfalls. It also means my application can remain very simple. Ie. I don't need to think about things like Celery or Redis or handling locking meticulously.
- veli_joza 9y agoThe cooperative multitasking is mentioned in "Why events are a bad idea" as a counter-argument #3. They are considered under threads category. It's unfortunate that only some languages support them.
- MichaelMoser123 9y ago> It's unfortunate that only some languages support them. yes, you need runtime support for this feature. If it is impossible to change the runtime than it can't be done for the language; now the runtime may have problem to work with a very limited stack for example, or the runtime is big and difficult to change (like the JVM), or it has long library functions that cannot yield to other co threads. However C/C++ or other languages that do not sit on top of a big runtime dont have that problem.