5 ms·

Fascinating talk. The overall approach here strikes me as being extremely influenced by QNX's design. Send/Receive/Reply as a messaging primitive is too often o

Fascinating talk. The overall approach here strikes me as being extremely influenced by QNX's design. Send/Receive/Reply as a messaging primitive is too often overlooked, and provides incredibly powerful that (as Cliffe mentions) renders an enormous amount of scheduling complexity as moot. Anyone who's done the UWaterloo trains course will recognize these patterns immediately, and (IIRC) interrupt dispatching is was done in a similar manner there as well. Finally, the supervision patterns here strike me as being very similar to those within the BEAM, and remind me of the infamous quote from Robert Virding (http://erlang.org/pipermail/erlang-questions/2008-January/032226.html http://erlang.org/pipermail/erlang-questions/2008-January/03...). Obviously a necessary reimplementation here, but humorous nonetheless. Great project, great talk.

steveklabnik 5y ago
QNX is an explicit influence, yes.
- bcantrill 5y ago
  And, transitively, Thoth![0] [0] https://en.wikipedia.org/wiki/Thoth_(operating_system) https://en.wikipedia.org/wiki/Thoth_(operating_system)
  - mcmatterson 5y ago
    https://www.youtube.com/watch?v=031vKBPk5eA https://www.youtube.com/watch?v=031vKBPk5eA
mcmatterson 5y ago
I couldn't stop thinking about this, so I went back and dug up an ancient (20yo+) copy of my OS implementation for the trains course (mat(t)OS). Sure enough, we did indeed dispatch the upper half of interrupts to processes, albeit via a dedicated blocking syscall rather than send/receive/reply semantics. Bottom half handlers (which were implemented behind task gates and had persistent stacks) just did the standard bottom half stuff: disabling interrupts & managing state so we could properly unroll after the interrupt had been handled. What a throwback! Interrupt code is at https://gist.github.com/mtrudel/c29fa60e5b2f3b6fdc46a9e3c65deb20 https://gist.github.com/mtrudel/c29fa60e5b2f3b6fdc46a9e3c65d.... I've been meaning for years to clean this stuff up and resurrect it. Maybe this is the kick in the ass I need to finally do so!

steveklabnik 5y ago

QNX is an explicit influence, yes.

bcantrill 5y ago
And, transitively, Thoth![0] [0] https://en.wikipedia.org/wiki/Thoth_(operating_system) https://en.wikipedia.org/wiki/Thoth_(operating_system)
- mcmatterson 5y ago
  https://www.youtube.com/watch?v=031vKBPk5eA https://www.youtube.com/watch?v=031vKBPk5eA

mcmatterson 5y ago

I couldn't stop thinking about this, so I went back and dug up an ancient (20yo+) copy of my OS implementation for the trains course (mat(t)OS). Sure enough, we did indeed dispatch the upper half of interrupts to processes, albeit via a dedicated blocking syscall rather than send/receive/reply semantics. Bottom half handlers (which were implemented behind task gates and had persistent stacks) just did the standard bottom half stuff: disabling interrupts & managing state so we could properly unroll after the interrupt had been handled. What a throwback! Interrupt code is at https://gist.github.com/mtrudel/c29fa60e5b2f3b6fdc46a9e3c65deb20 https://gist.github.com/mtrudel/c29fa60e5b2f3b6fdc46a9e3c65d.... I've been meaning for years to clean this stuff up and resurrect it. Maybe this is the kick in the ass I need to finally do so!