4 ms·

Asking out of ignorance: won't a synchronous API block the entire process while the I/O is going on?

by hliyan 9y ago

masklinn 9y ago
Yes. Unless the underlying reactor/scheduler is multithreaded but that's… uncommon, as async code tends not to consider thread-safety. It certainly isn't the case for nodejs. One could wonder whether that's an issue when IO are fairly short & strongly interspersed with code being run though, the overhead of switching tasks could be higher than the IO you're synchronising. I guess whether this is a good idea would strongly depend on how you're using sqlite (aka do you tend to make lots of very simple requests with small output or a smaller number of more complex ones).
- zbentley 9y ago
  > One could wonder whether that's an issue when IO are fairly short & strongly interspersed with code being run though IMO one of the core observations made by Dahl and the other Node.js folks was that this is very very rarely the case in modern web applications. Most webapps either a) spend the vast majority of their time waiting on IO, b) have non-IO code very regularly interspersed with IO operations (making event-loop based interleaving based on IO boundaries more useful) or c) both. As a result, Node.js was built with the single-thread/IO-bounded reactor model. I think that this, along with (and perhaps even more than) its choice of language syntax, drove the platform's adoption. It means that code doesn't need to think about thread safety, and that there is only one IO model: asynchronous by default (yes there are exceptions, but they're a minority). That lets users get a lot of scale for free, provided their workloads meet those criteria.
wruza 9y ago
This question implies a complexity of solutions and tradeoffs that I’m not ready to explain right now. In short: in node - yes, but this also simplifies everything by an order of magnitude until you’re too busy in sqlite. Node is not actually complex or well-designed [imo]. Other approaches could smoothen delays to ~zero. Other languages could even get rid of callbacks and promises.
- woah 9y ago
  The power of node’s approach is that it works well for everything except for processor intensive code at the cost of some syntactic overhead that has now been mostly resolved by async await. Much less mental burden than threads or coroutines with mutexes etc
  - wruza 9y ago
    I’m very interested in coroutine-based event loops. Can you please share your experience with these? Which framework did you use, programming language, etc. Why didn’t they “click” and what caused burden? Thanks in advance.
bpicolo 9y ago
Definitely, but when working with a local sqlite instance where your OS is page caching pretty much the whole thing your IO cost isn't necessarily that high. The trivial case of query-by-id almost boils down to a btree lookup in RAM I would think?

Asking out of ignorance: won't a synchronous API block the entire process while the I/O is going on?

by hliyan 9y ago

Asking out of ignorance: won't a synchronous API block the entire process while the I/O is going on?

Yes. Unless the underlying reactor/scheduler is multithreaded but that's… uncommon, as async code tends not to consider thread-safety. It certainly isn't the case for nodejs. One could wonder whether that's an issue when IO are fairly short & strongly interspersed with code being run though, the overhead of switching tasks could be higher than the IO you're synchronising. I guess whether this is a good idea would strongly depend on how you're using sqlite (aka do you tend to make lots of very simple requests with small output or a smaller number of more complex ones).

zbentley 9y ago
> One could wonder whether that's an issue when IO are fairly short & strongly interspersed with code being run though IMO one of the core observations made by Dahl and the other Node.js folks was that this is very very rarely the case in modern web applications. Most webapps either a) spend the vast majority of their time waiting on IO, b) have non-IO code very regularly interspersed with IO operations (making event-loop based interleaving based on IO boundaries more useful) or c) both. As a result, Node.js was built with the single-thread/IO-bounded reactor model. I think that this, along with (and perhaps even more than) its choice of language syntax, drove the platform's adoption. It means that code doesn't need to think about thread safety, and that there is only one IO model: asynchronous by default (yes there are exceptions, but they're a minority). That lets users get a lot of scale for free, provided their workloads meet those criteria.

wruza 9y ago

This question implies a complexity of solutions and tradeoffs that I’m not ready to explain right now. In short: in node - yes, but this also simplifies everything by an order of magnitude until you’re too busy in sqlite. Node is not actually complex or well-designed [imo]. Other approaches could smoothen delays to ~zero. Other languages could even get rid of callbacks and promises.

woah 9y ago
The power of node’s approach is that it works well for everything except for processor intensive code at the cost of some syntactic overhead that has now been mostly resolved by async await. Much less mental burden than threads or coroutines with mutexes etc
- wruza 9y ago
  I’m very interested in coroutine-based event loops. Can you please share your experience with these? Which framework did you use, programming language, etc. Why didn’t they “click” and what caused burden? Thanks in advance.

bpicolo 9y ago

Definitely, but when working with a local sqlite instance where your OS is page caching pretty much the whole thing your IO cost isn't necessarily that high. The trivial case of query-by-id almost boils down to a btree lookup in RAM I would think?