In some weird cases (embedded devices, perhaps RaspberryPi based) you could have a Linux kernel (see kernel.org & kernelnewbies.org for details) managing a very limited set of processes.
You could even write your own
then you have control over the set of processes entirely.
(see init(1)) so that it fork(2)-s very few child processes and uses other syscalls(2).
This Operating System textbook should give you more insights, and you'll learn a lot by compiling the Linux kernel from its source code. The first command to run is probably
make menuconfig (after having the entire Linux kernel tree on your local disk). Read also Advanced Linux Programming and signal(7), time(7), vdso(7).
However, observe than in 2020 most processors for Linux have at least two cores. And many Linux systems are using systemd, whose source code is open source (and you are allowed to study it and improve it). Other Linux systems could use runit (also open source). With care and inspiration from existing
init programs you could write your own.
You may want to see Linux From Scratch, and study the source code of your crt0 routines, and of GNU libc (it is free software, like GCC and GNU binutils and GNU bash are!) or musl-libc.
A related concept is that of continuations (a fancy name for reification of call stacks) and the call/cc primitive of Scheme. So read R5RS, ACM SIGPLAN conference proceedings (e.g. PLDI), Queinnec's book Lisp In Small Pieces, and Pitrat's book Artificial Beings and perhaps also this draft report (funded by CHARIOT). Be aware of Rice's theorem.
If you use GCC, don't forget to compile your
foo.c code as
gcc -Wall -Wextra -fverbose-asm -S foo.c then look inside
The OSDEV website also gives practical information about writing (and studying the source code of) operating system kernels. You could be interested by the Singularity software and FOSDEM and ACM SIGOPS conferences.
You may want to use
/proc/ (see proc(5)) then you could observe that your Linux kernel is processing interrupts quite often (typically hundreds of interrupts per second). Each interrupt (e.g. those triggered by HPET) is an occasion (for the Linux kernel) to schedule some other process.
If your hardware don't give hundreds of interrupts every second, you should discuss with the provider or designer of your hardware.
that process is doing some extremely long running computation without yielding
On Linux that never happens, unless your kernel or your hardware is buggy.
In user-space a process gets interrupted at least dozen of times per second (in 2020, on most hardware). Read about kernel preemption and context switch.
Observe that a context switch is changing the current continuation. At an abstract level, an interrupt is close to some
call/cc in Scheme.