Skip to content
This repository has been archived by the owner on Apr 22, 2023. It is now read-only.

Support for multiple event loops #7323

Closed
vkurchatkin opened this issue Mar 17, 2014 · 5 comments
Closed

Support for multiple event loops #7323

vkurchatkin opened this issue Mar 17, 2014 · 5 comments

Comments

@vkurchatkin
Copy link

Currently only uv_default_loop() is used, but since now loop is obtained from Env it could be changed for something else. This can be used implement custom blocking IO using existing non-blocking primitives.

The API can be derived from domain, because of the similarity (that is, grouping async operations):

var loop = require('event_loop').create();

// or loop.enter/loop.exit 
loop.run(function () {
  setTimeout(function () {
    console.log('This will show up first');
  }, 1000)
});

console.log('This will show up second');

Uncaught errors could be thrown from loop.run. Obviously, some changes in nextTick are required, as it should have queue per each event loop.

@OrangeDog
Copy link

What's the point of using a second event loop, if it blocks the first one?

@vkurchatkin
Copy link
Author

The same as readFileSync, execSync, etc.

@jimmiehansson
Copy link

This is an interesting topic, could you touch a bit more on the topic of how it could benefit proper node development though?

@vkurchatkin
Copy link
Author

@jimmiehansson well, as I have already mentioned it is intended for same set of use cases as existing "sync" functions. That is, initialization and scripting, to name some. Let's say we have a configuration step that pulls some data from file system synchronously. There is no easy way to plug in some other source of that data, because most of IO doesn't have synchronous capabilities. With proposed API we could just do:

var loop = require('event_loop').create();

function configure () {
  var data;
  require('event_loop').create().run(function () {
    getDataSomehow(function (err, res) {
      if (err) throw err;
      data = res;
    });
  });
  return data;
}

You can think of this as an "inlined" execSync of a node script, but in the same process and context.

Anyway, I don't think this will ever happen, because: 1. no one cares; 2. you definitely can live without it, especially with generators and stuff; 3. it requires huge refactoring with possible performance drop.

@jimmiehansson
Copy link

@vkurchatkin Its an interesting idea. But I do have to agree, I highly doubt it will be brought to the table. Thanks for the explanation!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants