[bind10-dev] Non-preemptive threads as an alternative to events?

[Francis Dupont]

> Basically, locking sucks, and that's why threads suck. :)

=> this takes a short path: it assumes concurrent access including
write access to data structures is implied by threads.
This is not true so the real reasoning is:
concurrent R/W access requires locking, locking sucks so threads
using concurrent R/W access sucks.

> The idea here is that you only switch context during well-defined points
> in the program

=> it is bound to not preemptive. BTW there were a lot of not
preemptive systems: old Unix kernels, old MacOS, etc.
This simplifies programming at the cost of a lost in reactivity
(this is why real time OSs are preemptive) and of course if a task
loops without checking if it must release the CPU it loops for ever.

> The drawback is that you can only use a single CPU at a time, since
> you are only ever executing a single thread at a time. But that works
> okay for servers that mostly spend their lives waiting on network I/O.

=> if you can use a single CPU at a time it is simpler to forget
threads directly, isn't it?

Regards

Francis Dupont <fdupont at isc.org> (as a researcher in parallel
functional programming languages in a previous life).