are there any javascript libraries which provide promises and futures syntactically similar to that of C++ ones. basically we want to use them in webworkers, I dont want a callback interface. I want the webworker to block on a future and continue when the UI thread sets the value of the future. i have looked at every possible promise and future library but every thing expects a callback, our code is already a mess and we dont want to further complicate it.
http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses-promise.js
Implementation of promises for SES/ES5. Exports Q to the global scope.
Mostly taken from the ref_send implementation by Tyler Close, with the addition of a trademark table to support promises for functions.
Btw, Mark Miller is working on codifying JavaScript's concurrency model and adding eventual send semantics with syntactic sugar for a future version of the language. From http://wiki.ecmascript.org/doku.php?id=strawman:concurrency
Reality: Codifying and formalizing JavaScript’s de-facto concurrency model as a de-jure model.
Promises: A way to (Q(p).post(), Q(p).get()) Make asynchronous requests of objects that may not be synchronously reachable, such as remote objects. (Q(p).when()) Ease the burden of local event loop programming, by reifying the ability to register a callback as a first class value. (Q.async, yield:) for implicit registration of shallow continuations on promises.
Syntactic sugar. The infix “!” operator: An eventual analog of “.“, for making eventual requests look more like immediate requests.
(Q.makePromise()) A promise extension mechanism, so that promise handlers can turn local promise operations into remote messages.
Transport independence: Using remote object messaging as a symmetric abstraction layer, hiding the annoying differences among the various transports listed above as well as server-to-server TCP and UDP transports.
(Vat()) An event-loop spawning mechanism for spawning new event loops that run concurrently with the event loop which spawned it.
Worker independence: Using Vat API as an abstraction layer around worker spawning on the browser or process spawning on the server.
(Vat.evalLater(), where()) Using JavaScript itself as mobile code, so event loops can safely inject new behavior into other event loops
Symmetric Mobile Code: Generalizes from the current use of JavaScript as mobile code sent only from server and only to browsers.
Async-PGAS: Provides a distributed analog to the expressiveness of The Asynchronous Partitioned Global Address Space Model.
Related
How do the NodeJS built in functions achieve their asynchronicity?
Am I able to write my own custom asynchronous functions that execute outside of the main thread? Or do I have to leverage the built in functions?
Just a side note, true asynchronous doesn't really mean anything. But we can assume you mean parallelism?.
Now depending on what your doing, you might find there is little to no benefit in using threads in node. Take for example: nodes file system, as long as you don't use the sync versions, it's going to automatically run multiple requests in parallel, because node is just going to pass these requests to worker threads.
It's the reason when people say Node is single threaded, it's actually incorrect, it's just the JS engine that is. You can even prove this by looking at the number of threads a nodeJs process takes using your process monitor of choice.
So then you might ask, so why do we have worker threads in node?. Well the V8 JS engine that node uses is pretty fast these days, so lets say you wanted to calculate PI to a million digits using JS, you could do this in the main thread without blocking. But it would be a shame not to use those extra CPU cores that modern PC's have and keep the main thread doing other things while PI is been calculated inside another thread.
So what about File IO in node, would this benefit been in a worker thread?.. Well this depends on what you do with the result of the file-io, if you was just reading and then writing blocks of data, then no there would be no benefit, but if say you was reading a file and then doing some heavy calculations on these files with Javascript (eg. some custom image compression etc), then again a worker thread would help.
So in a nutshell, worker threads are great when you need to use Javascript for some heavy calculations, using them for just simple IO may in fact slow things down, due to IPC overheads.
You don't mention in your question what your trying to run in parallel, so it's hard to say if doing so would be of benefit.
Javascript is mono-thread, if you want to create 'thread' you can use https://nodejs.org/api/worker_threads.html.
But you may have heard about async function and promises in javascript, async function return a promise by default and promise are NOT thread. You can create async function like this :
async function toto() {
return 0;
}
toto().then((d) => console.log(d));
console.log('hello');
Here you will display hello then 0
but remember that even the .then() will be executed after it's a promise so that not running in parallel, it will just be executed later.
Most NodeJS programmers know why it's bad to block NodeJS's single-threaded event loop. For example, when reading a file, we know it's better to use fs.readFile instead of fs.readFileSync. My question is: how does one go about creating an asyn API in the first place if the underlying task to be performed by the API is inherently synchronous? Another words, how do I go about creating an API such as fs.readFileSync, and not use the event-loop thread to perform the underlying task? Do I have to go outside of NodeJS & Javascript to do this?
how does one go about creating an asyn API in the first place if the
underlying task to be performed by the API is inherently synchronous?
In node.js, there are the following choices for creating your own asynchronous operation:
Base it on existing async operations (such as fs.readFile()). If your main operation itself is synchronous and can only be done synchronously in node.js, then this option would obviously not solve your problem.
Break your code into small chunks using setTimeout(), setImmediate() or nextTick() so that other things can interleave with your operation and you won't block other things from sharing the CPU. This doesn't prevent CPU usage, but it does allow sharing of the CPU with other operations. Here's an example of iterating over an array in chunks that doesn't block other operations from sharing the CPU: Best way to iterate over an array without blocking the UI.
Move your synchronous operation into another process (either another node.js process or any other process) that can do its thing and then communicate back asynchronously when done using any appropriate inter-process communication mechanism (TCP, stdio, etc...).
Write a node.js plug-in where you have the ability to use native OS threading or native IO events and you can then create a new operation in node.js that has an async interface.
Do I have to go outside of NodeJS & Javascript to do this?
Items #1, #2, #3 above can all be done from Javascript. Item #4 involves create a native code plug-in (where you can have access to native threading).
Another words, how do I go about creating an API such as
fs.readFileSync
To truly create an API like fs.readFileSync() from scratch, you would have to use either option #3 (do it synchronously, but in another process and then communicate back the result asynchronously) or option #4 (access OS services at a lower level than is built into node.js via a native code plug-in).
Does the EcmaScript specification place any constraints on the process model used to implement the runtime?
For example, is the event loop required to be on a separate thread from the thread managing the runtime communication with the operating system IO subsystems?
No, it does not specify anything about those. Runtime communication and IO are not even part of the language, they come as implementation-dependent exotic objects.
The ECMAScript specification does not even use the term "event loop", though it does define Jobs and Job Queues which work similar. There is no reason however to implement those with multiple threads, after all, JS alone always runs sequentially.
In contrast, the HTML5 spec does define event loops and even a process model, but there is no requirement about multithreading either.
To be clear, I'm hoping for factual information to be presented about RxJS and how it relates to JavaScript's evolution, not a matter of opinion on how good RxJS is, etc.
My question is: is RxJS ( https://github.com/Reactive-Extensions/RxJS ) somewhat of a forward-looking polyfill because of Object.observe, etc. not being standard among browsers yet, or does it fundamentally offer things beyond the scope of what native JS offers and beyond what JS standards seek to offer in the foreseeable future? (Granted, perhaps someday native JS may be capable of X, Y, Z that aren't currently on the radar; I'm not interested in guesses on those.) Perhaps it's a combo.
My motivation/interest in the question is in considering the investment of learning and implementing RxJS in applications, weighed against the timeline of native JS solutions being available, and/or whether there are other considerations to be mentioned that I have not touched on here.
RxJS was birthed as a JavaScript port of Rx.NET. It is not a forward looking polyfill of Object.observe.
RxJs is a library for working with asynchronous operations, with special emphasis on multi-valued operations. The library gives the developer a common "language" they can use to write functional code to manipulate asynchronous streams no matter the stream source. The same "language" works with any combination of UI events, timer events, object mutation observations, animation frames, ajax calls, websocket messages, webworker messages, promises, etc
Object.observe is a mechanism to observe changes in an object. RxJS does not provide this functionality. But RxJS complements this functionality: As an object is changed over time, it can be thought of as a source of asynchronous object change notifications. It is fairly straight-forward to convert these observations into an RxJS source, (e.g. something like Rx.Observable.observeObject(someObject)), which would then let you work with object changes as just another asynchronous RxJs stream with all of the vast array of tools RxJS makes available to you.
RxJs is the library which helps us to do Reactive Programming.
Reactive Programming is a pattern of development that works with asynchronous data stream created of UI Events, HTTP Requests, File System, cache etc. So data stream is an ongoing event sequence in time orderly manner. The stream can emit value, error, and status signal.
Observables are to watch these streams and trigger function on anything occurs in the stream. Observers can subscribe to observables.
Ref- http://technobelities.blogspot.in/2017/02/rxjs-quick-start.html
As per MSDN -
Reactive Extensions (Rx) is a library for composing asynchronous and event-based programs using observable sequences and LINQ-style query operators. Reactive Extensions represents all these data sequences as observable sequences. An application can subscribe to these observable sequences to receive asynchronous notifications as new data arrive.
I read that the javascript language has characteristics that assist in the implementation of non-blocking IO which contributes to the success of projects like node.js. My question is what are these characteristics and why is non-blocking IO trickier to implement in other languages?
JavaScript itself does not provide non-blocking IO. The underlying system calls that node.js uses do the non-blocking IO. JavaScript's first-class functions mean that it is easy to pass callbacks around when IO has completed.
Other languages can do non-blocking IO just fine. node.js just argues that callbacks make it super-easy to reason about and handle non-blocking operations.
Ruby has EventMachine, which passes blocks around instead of functions. C can do non-blocking IO with function pointers, but then you don't get closures, so it is a bit more of a pain.
The reason that javascript is sometimes labeled as a non-blocking IO is because of the concept of anonymously defined, (event based), functions. Node.js specifically labels this as their reasoning why javascript is a good server side language. This however, is only a half truth, as it is not technically non-blocking, but it will continue to execute code while waiting for a callback from an anonymous callback/ajax function. I'm not sure if this is what you read, but an explanation offered in one Node tutorial is:
"The other method, the one taken by Node and some extremely fast modern servers such as Nginx and Thin, is to use a single non-blocking thread with an event loop. This is where the decision to use JavaScript really shines, since JavaScript was designed to be used in a single threaded event loop-based environment: the browser. JavaScript’s ability to pass around closures makes event-based programming dead simple. You basically just call a function to perform some type of I/O and pass it a callback function and JavaScript automatically creates a closure, making sure that the correct state is preserved even after the calling function has long since gone out of scope."
source: http://net.tutsplus.com/tutorials/javascript-ajax/this-time-youll-learn-node-js/
In reference to your multithreading tag, Node.js and Javascript are NOT multithreaded, they use a system of closures to preserve state while waiting for a callback. Therefore, they are NOT completely non-blocking. There are plenty of scenarios where blocking can occur, but for most small implementations, a developer will never encounter a blocking situation.
see here for possible info on why node.js is bad: http://teddziuba.com/2011/10/node-js-is-cancer.html (Link broken)
and here for a rebuttle: http://rhyolight.posterous.com/nodejs-is-not-cancer (Link broken)
Asynchronous functions are usually event-based in JavaScript, which means registering callback-handlers. Your code runs on after the registration, but does not wait for the event - everything to be done after a event must be invoked from the handler. I hope that says all.
Of course there are exceptions, like window.alert / confirm / prompt in browsers.
https://youtu.be/dFnkZ15-_0o?t=2125 This excerpt from Andrew Mead's node.js course does a great job of visually explaining the differences between non-blocking and blocking I/O operations in JS. The clip is from 35:25 - 47:16.