Re: [TUHS] A/UX [was Linux is on-topic]

[Bakul Shah <bakul@iitbombay.org>]

On Jul 21, 2020, at 8:13 PM, tytso@mit.edu wrote:
> 
> The issue is that there aren't that many good real-time programmers
> Tavailable.  Furthermore, many real-time applications need to do a lot
> more than data acquisition, so having access to POSIX API's in the
> real time task is very attractive.  Sure, you can try to interchange
> information between the real-time task and the POSIX task, but that's
> a lot more complicated, and that's where the "not enough real-time
> programmers" rears its head again.
> 
> ...
> Sure, there will be some number of real-time task which needs
> single-digit millisecond real-time guarantees --- in which case you
> can write it in C using Real-time Linux.  And for those really cases
> where you need latencies which are in the tens of microsecnds; then
> yeah, at that point you might need specialized OS's.  But the cases
> where you need fast, hard real-time is pretty rare compared to those
> cases where real-time Java is sufficient.


The approach taken by Massalin in their Synthesis Kernel seemed quite
promising. By using runtime code synthesis they were able to run realtime
music synthesis at 25Khz sampling rate on a 20Mhz 68K machine. Too bad
these ideas didn't take off. I wanted to use similar ideas in lieu of
code like netgraph (in FreeBSD) or N layers of networking code but no
tools existed. Today, on a computing device your browser may freeze
for a few seconds due to garbage collection or whatever. 

Seems to me, a bigger issue than not-enough-real-time-real-programmers
is a lack of good real time programming abstractions and tools. No way
to specify or test a timing budget or required maximum latency. There
are things like CBQ (class based queueing) for managing traffci flows
but no such general purpose support for mapping code to hardware to
meet timing and latency requirements.