Preemption and Time-Sharing

Function-based-paradigm engines tend to need to implement preemptive operating systems as part of the engine. That’s because functions block when calling other functions. Functions must suspend operation until the callee returns a result. That’s clearly anti-asynchronous and this paradigm should not be used for expressing asynchronous programs. There must be better ways to express asynchronousity than forcing a function-based-paradigm mindset onto the problem.

In the 1950s, CPUs were so expensive that it was considered necessary to spend human time to invent time-sharing. Because functions cause blocking in willy-nilly, ad-hoc manners, operating systems need to wrench control away from the currently running program by using the sledge-hammer of hardware preemption. Extra code is needed for doing this. Function-based engines implement this extra code and call it context switching. Could we use mutual multitasking and closures instead? Yes, but, we don’t. It was noticed that apps tend to clobber one another and a single, general fix was invented - preemption and context switching. Apps clobbering other apps is not OK, but, parts of the same program clobbering other parts of the same program is commonly encountered and accepted. This is so common, that we have invented a special word for this situation - “bug”.

See Also

References: https://guitarvydas.github.io/2024/01/06/References.html

Blog:

https://guitarvydas.github.io/

Videos: https://www.youtube.com/@programmingsimplicity2980

Discord: https://discord.gg/Jjx62ypR

Leanpub: [WIP] https://leanpub.com/u/paul-tarvydas

Gumroad:

https://tarvydas.gumroad.com

Twitter: @paul_tarvydas