Open facekapow opened 9 years ago
Threads are not supported at the moment, mainly because of the complexity they would introduce. Just curious, what's your usecase?
So that background jobs could be run (like daemons).
well, nothing really prevents running background jobs provided they don't block the system
Well, I need to run synchronous jobs in the daemon (which may take long and block the system).
The only available option right now is to use setImmediate
trick to split long-running tasks into smaller subtasks to prevent blocking.
How easy (or hard) would it be to implement threading into runtime? I could give it a shot over the weekend.
Depends on what kind of threading you'd like to implement, what scheduler and preemption mechanism to use, and a way to make it all thread-safe. I'm afraid it's an extremely complex task.
Ok, well, is there at least a way to launch another V8 instance?
yes, v8 has the concept of Isolate. In fact, runtimejs internally has some support for that, but it's not enabled. I'm actually trying to get rid of it, because it's very ugly and needs to be completely rewritten.
Just FYI, I think node tried to implement multiple isolates support, but then decided not to do it because of the amount of complexity (https://groups.google.com/forum/#!msg/nodejs/zLzuo292hX0/F7gqfUiKi2sJ).
Thanks, i'll take a look at it. But, how do you enable it?
Not really easy to enable as well. I'd say the first version could ship without threads/web workers support.
Oh well! Guess i'll just finish the RNG driver for now.
https://github.com/xk/node-threads-a-gogo/blob/master/README.md
https://github.com/audreyt/node-webworker-threads
https://github.com/nodejs/io.js/pull/1159
https://github.com/nodejs/io.js/pull/2133
http://wiki.ecmascript.org/doku.php?id=strawman:concurrency
Here are some examples of implementations to take inspiration from.
Woah! Threaded WebWorkers on Io.js! :-D
Not sure if The End is near, anyway... :-P El 11/07/2015 18:30, "Sam Tobia" notifications@github.com escribió:
https://github.com/xk/node-threads-a-gogo/blob/master/README.md
https://github.com/audreyt/node-webworker-threads
nodejs/io.js#1159 https://github.com/nodejs/io.js/pull/1159
nodejs/io.js#2133 https://github.com/nodejs/io.js/pull/2133
http://wiki.ecmascript.org/doku.php?id=strawman:concurrency
Here are some examples of implementations to take inspiration from.
— Reply to this email directly or view it on GitHub https://github.com/runtimejs/runtime/issues/75#issuecomment-120637700.
They do amazing things over there :3
Don't know if to ask them about to use a PID file and use it to fork() new Node.js processes instead of create fully new Node.js instance to don't waste so much memory on NodeOS, or ask them for a girlfriend, whatever come first... :-P El 11/07/2015 19:43, "Sam Tobia" notifications@github.com escribió:
They do amazing things over there :3
— Reply to this email directly or view it on GitHub https://github.com/runtimejs/runtime/issues/75#issuecomment-120647735.
I see workers as a part of runtime, but maybe after 1.0
@iefserge Yeah, I can't imagine threads being immediate. I just figured I'd provide whatever info I could since I I've spent (maybe too much) time looking up a variety of threading implementations. And if two of my interests collide, I can't help but pop my head in.
@piranna It seems like they are heavy implementing isolates
I don't know if that will help your cause or basically the same thing : / I have to imagine that require statements are the type of things that will ideally be shared. However, that may create other issues
Also Here's another Inspiring one What I really like about thread.js is how synchronous the code ends up looking while practically speaking looking like main logic.
I'm reopening this, since it may be added later.
@formula1 that's not the same. What I'm asking for is something similar to what LibreOffice or MS-Office or GEdit or Chromium or Firefox or other thousand programs do, that's when one instance is running and you try to exec a new independent one, the new one detect that's already one running (via a PID file or similar) and open the new file or webpage on the old instance instead, leading to use less memory resources, between other things because the .TEXT section can be shared when forking a process. The same could be done in Node.js, creating a new processes on the old instance for each new script to be executed, or also maybe use an isolate on a new thread (that's somewhat what they are doing internally with workers on that commit) to use less resources by running on the same process and don't have context switching. In that last case there would be problems with compiled modules since they are sharing the same memory space, but probably they have already fixed it.
I ask myself if now that there will be workers I could be able to implement this as a launcher on a Node.js module... Basically it would be to check the PID file and launch the apps in workers from the main process... :-P
Ah, That makes sense. Something along the lines of
var fs = require('fs');
if(fs.existsSync('./pid')){
fs.writeFileSync("./run", JSON.stringify(process.argv));
process.exit():
}
fs.writeFileSync("./pid", process.pid);
fs.watchFile("./run",function(event){
var args = fs.readFileSync("./run).toString("UTF8");
if(args === "") return;
fs.writeFileSync("./run", "");
runProgramInThread(JSON.parse(args));
});
runProgramInThread(process.argv);
Obviously this example would be pretty bad since there would likely race conditions when multiple commands were running at once (A Server might be preferred). Honestly, That sort of system seems pretty straight forward I can see it more valuable in user land than in core.
Ah, That makes sense. Something along the lines of
Yes, sort of, only that maybe using named pipes or domain sockets instead of filesystem files (so no race conditions here anymore :-P). In fact, the PID file itself would be a named pipe, I think this is usually done in Plan9... :-) I supossed it would be simple, but not SO simple... :-D The most complicated part would be the runProgramInThread()
function due to the need of the initialization of the Worker, but when they get implemented probably wouldn't be something more that an afternoon project... :-)
That sort of system seems pretty straight forward I can see it more valuable in user land than in core.
runtime.js core, or Node.js core? I think in Node.js it makes sense in both of them, although in some cases it would make sense to dispatch new real processes too, like for example when using different permissions (UID & GID, for example)... Anyway, I think this could (should?) be integrated on NodeOS to fix the memory consumption it has.
Anyone know what happend to the preemtible_threads branch? Can it still be used, at least with some modifications?
It was an experiment to add preemptive multitasking using v8 isolates and v8 stack interrupts. It was very unstable and crashed frequently, and I had to patch v8 for it to work.
Does runtime.js support multiple threads? So that I could make some parts not block the system?