runtimejs / runtime

[not maintained] Lightweight JavaScript library operating system for the cloud
http://runtimejs.org
Apache License 2.0
1.93k stars 127 forks source link

Threads #75

Open facekapow opened 9 years ago

facekapow commented 9 years ago

Does runtime.js support multiple threads? So that I could make some parts not block the system?

iefserge commented 9 years ago

Threads are not supported at the moment, mainly because of the complexity they would introduce. Just curious, what's your usecase?

facekapow commented 9 years ago

So that background jobs could be run (like daemons).

iefserge commented 9 years ago

well, nothing really prevents running background jobs provided they don't block the system

facekapow commented 9 years ago

Well, I need to run synchronous jobs in the daemon (which may take long and block the system).

iefserge commented 9 years ago

The only available option right now is to use setImmediate trick to split long-running tasks into smaller subtasks to prevent blocking.

facekapow commented 9 years ago

How easy (or hard) would it be to implement threading into runtime? I could give it a shot over the weekend.

iefserge commented 9 years ago

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.

facekapow commented 9 years ago

Ok, well, is there at least a way to launch another V8 instance?

iefserge commented 9 years ago

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).

facekapow commented 9 years ago

Thanks, i'll take a look at it. But, how do you enable it?

iefserge commented 9 years ago

Not really easy to enable as well. I'd say the first version could ship without threads/web workers support.

facekapow commented 9 years ago

Oh well! Guess i'll just finish the RNG driver for now.

formula1 commented 9 years ago

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.

piranna commented 9 years ago

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.

formula1 commented 9 years ago

They do amazing things over there :3

piranna commented 9 years ago

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.

iefserge commented 9 years ago

I see workers as a part of runtime, but maybe after 1.0

formula1 commented 9 years ago

@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.

facekapow commented 9 years ago

I'm reopening this, since it may be added later.

piranna commented 9 years ago

@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

formula1 commented 9 years ago

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.

piranna commented 9 years ago

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.

facekapow commented 9 years ago

Anyone know what happend to the preemtible_threads branch? Can it still be used, at least with some modifications?

iefserge commented 9 years ago

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.