"The design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design." - http://jehanne.io
I've been looking for examples of good comments about simplicity to help focus my own view of simple. I love the quote above.
"In a way the so called “New Jersey style” was a rush for a minimum viable product able to minimize the time-to-market and to gain the first mover advantage."
Another way of looking at it is that it is an attempt to get something into existence, rather than waiting years for perfection and ending up with nothing. To paraphrase performance work, something is infinitely better than nothing.
I am somewhat interested in the comment, "(the mindful reader will notice that alarm is still waiting to be moved to user space… the fact is that it’s too boring of a task!)" I originally interpreted it as meaning userspace could interrupt the blocking call, but I see its actually a filesystem that interacts with kernel space.
fd = create("/dev/alarms/new", ~0, pair_ints(getpid(), ms))
> [asymptotic graph trending towards doom]
> How many programs are you running right now? :-D
I don't even know, there are probably thousands of processes running right now, totaling hundreds of millions of lines of code.
And it all works perfectly fine, especially as long as I don't update anything. I just don't do the things that don't work. The things that don't work, they generally don't work 100% of the time. The things that do work, they generally work 100% of the time. Some software might fail randomly and frequently, in which case I might not use it either, unless failure is easily recovered from (which is often the case).
I don't need a system that is really simple and (as a consequence) super-reliable. I need a system that runs my software and that is fault-tolerant. After all, even entirely correct software cannot prevent hardware faults (which do occur).
Correct me if I'm wrong, but doesn't this suffer from a race condition? What if a process requests an awake, but then gets preempted before doing the blocking system call, and then gets awakened in response to its awake request (rather than because of normal scheduling)? Its awake request was already serviced, so if it performs a blocking syscall, it will wait indefinitely.
Alternatively, if the awake request is only done when a blocking syscall is done, doesn't it then suffer from the problem that a random buggy library function could request an awake without then doing a blocking syscall (due to whatever logic bug), so then when the process does a blocking syscall that it expects to block indefinitely, it instead gets a syscall with a timeout?
Wouldn't it be better for the awake syscall to take another syscall as a parameter (pretty simple to do in assembly and should be provided as a C library wrapper), in order to guarantee atomicity?