ATC? Or the routing of the messages thru AX25? If it were the whole ATC... that's pure madness, because EMACS' GC and 'real time ATC' concepts are absolutely anthagonic.
znpy 2 hours ago [-]
> EMACS' GC and 'real time ATC' concepts are absolutely anthagonic
it might not be the case.
"real time" is often a very misunderstood concept. most things can be "real time" depending on the context.
"real time" really just means that the timeframe the control system takes to react is shorter than the time frame the controlled system takes to change state (for any sufficiently vague definition of "change").
so even if a GC cycle in emacs took, say, 200 msec, it could have still been completely fine as long as the "stuff" more less than, say, every 500 msec (the numbers here are completely bogus).
not to mention, many programming environments where memory is usually managed and garbage-collected also do offer some way to do varying degrees of manual memory management, if you want to. that might have been the case.
and as of last resort... you could always manage memory outside of the programming language runtime.
Some discussion then: https://news.ycombinator.com/item?id=26202517
it might not be the case.
"real time" is often a very misunderstood concept. most things can be "real time" depending on the context.
"real time" really just means that the timeframe the control system takes to react is shorter than the time frame the controlled system takes to change state (for any sufficiently vague definition of "change").
so even if a GC cycle in emacs took, say, 200 msec, it could have still been completely fine as long as the "stuff" more less than, say, every 500 msec (the numbers here are completely bogus).
not to mention, many programming environments where memory is usually managed and garbage-collected also do offer some way to do varying degrees of manual memory management, if you want to. that might have been the case.
and as of last resort... you could always manage memory outside of the programming language runtime.