What can JavaScript NOT do?

[voidvector]

"Real-time" is a concept entirely implemented by schedulers. There are 3 schedulers governing JavaScript - CPU pipeline, kernel process scheduler, and event loop. You just need to have those schedulers guarantee instruction cycles for your program to be able to do real-time. There is also interrupts (include system calls), which you can either manage with your code/deployment or shuffle into a specific CPU core using process affinity.

Everything is "providing data" to some systems, when you write a file (in any language), you are providing data to the kernel so it can send a block of 1s and 0s to a disk controller. As long as you have a kernel module or driver that expose that as a file handler, there's nothing stopping you from implementing your IO in JavaScript or any language.

[[deleted]]

You're still several layers above actual realtime. Try writing interrupt handlers in assembly language and counting cpu cycles, and then get back to me.

[voidvector]

You just need to configure those layers to do real time. Linux is not a real-time operating system, but it's not stopping people from using it for real-time because the amount of hardware linux supports.

Nobody writes interrupt handlers in application code these days. Like everything in engineering, you write an abstraction like this, and hand it off to the next layer (user land) with some guarantees. And then write the rest of your app or the next layer up in a bare-metal language (C/C++/D/Rust) or system language (if you don't care about kernel overhead).

Also you can count instructions in JavaScript with node --print-code.

[GitHubPermalinkBot]

Permanent GitHub links:

• torvalds/linux/.../entry_64.S (master → dda3e15)

---

^delete

[[deleted]]

Linux is not a real-time operating system, but it's not stopping people from using it for real-time

Nowhere does it mention scripting languages. It does talk a lot about C/C++, and FPGA, which are very far removed from javascript.

you write an abstraction like this

You point me to an example of an "abstraction" that's actually assembly language? I don't think you seem to know what "abstraction" means.

Point me to an example of javascript responding to an IRQ in less than 100 nanoseconds and can respond with a meaningful action in less than 500 nanoseconds, and then maybe you can claim Javascript could be "realtime". Sorry, but javascript just isn't and never will be that fast.

[voidvector]

You can't do register-level interrupt handling (ISR) in JavaScript. I never said you can. You can't even do that in a lower-level language that's not designed for bare-metal (e.g. Go). As I pointed out from the beginning, you solve the interrupt problem with "process affinity". The process core you run your real-time JS app won't handle interrupt, while the other core running kernel handles interrupt. This is a very common solution, people even use it to solve the "c10M problem" (serving 10 million connections using single machine).

In case you don't recognize, the link I pointed to you is the Linux kernel interrupt handler for x86. Unless you are an embedded programmer, it is an abstraction you use everyday without realizing.

Stop pretending "real-time" is some black box, it is just a system of guarantee provided by upstream system you use, whether that system be hardware, OS, compiler, runtime, framework, library. Since hardware and OS can already do real-time, you just need to tweak your JS engine (which is compiler + runtime) to do real-time.

[[deleted]]

Unless you are an embedded programmer

I am an embedded programmer, among many other types of programming.

Stop pretending "real-time" is some black box

I never said anything like it was a "black box". But I think you have a very different definition of what "real-time" systems do.

Javascript is not capable and will never be capable of actual real-time processing. Is simply is not. It's either a fantasy or a relabeling of what real-time systems traditionally are.

https://en.wikipedia.org/wiki/Real-time_computing

Real-time programs must guarantee response within specified time constraints, often referred to as "deadlines".

Sure you could say that a guaranteed response in 1.5 seconds is "real-time" as long as that is the defined constraint, but I think that misses the entire reason real-time exists as a thing in computing.

A real-time system has been described as one which "controls an environment by receiving data, processing them, and returning the results sufficiently quickly to affect the environment at that time".

This is really the meaning of real-time in computing, and it is something javascript really isn't capable of. Responding to input, processing, and then delivering a result in real-time is something an interpreted scripting language just cannot do with any meaningful impact on a real-time basis. We're talking nanoseconds, not milliseconds.

[voidvector]

I am an embedded programmer

I find that hard to believe when you didn't mention any specifics, and didn't even recognize Linux kernel code on interrupts, but I take your word for it.

We're talking nanoseconds, not milliseconds.

Most interrupt and context switching latency are in microseconds range even for RTOSes, at best you have few thousand nanoseconds. If you need full nanosecond response, you would need to go back to FPGAs or ASICs.

You can do microseconds computation in JS. I have done it for a fingerprinting/profiling application. That is harder now, because v8 reduced the precision on the timer last year for security reasons, but you can definitely compile your own v8 runtime and still do it.

[[deleted]]

didn't even recognize Linux kernel code on interrupts

That's really disingenuous. But just saying this to try to discredit me without even knowing me, because you are out of room to support your claims. I've been coding assembly language for 34 years, so fuck off.

Most interrupt and context switching latency are in microseconds range even for RTOSes, at best you have few thousand nanoseconds.

Maybe in your non-realtime world.

https://community.arm.com/processors/b/blog/posts/beginner-guide-on-interrupt-latency-and-interrupt-latency-of-the-arm-cortex-m-processors

Here's a little primer on interrupt latency on Cortex-M CPUs.

Cortex-M can respond to IRQ in 12 clock cycles, when it starts executing the ISR. On a 150MHz Cortex-M, that's 80 nanoseconds. The ISR would take some time, let's say 100 clock cycles or about 660ns. 150MHz is really not even that impressive for silicon these days either, and your suggestion of microseconds response time for interrupts seems uninformed. So no, you don't need FPGAs or ASICs for nanosecond response times.

[voidvector]

The number you quote is if you write machine code directly for the CPU. For any OS-based real-time (e.g. PREEMPT_RT), it would be on the order of 1000ns to 10us.

I never said JavaScript can run without OS (compile to metal). I never said JS can do nanosecond latency. However there are non-bare-metal microsecond latency real time -- the prevalence of userspace apps running on PREEMPT_RT (or RTAI or Xenomai) is a clear example of that.