DEV Community

loading...

Discussion on: NodeJS Non-Blocking Processing

Collapse
qm3ster profile image
Mihail Malo

With rescheduling when empty, consider:

const {log} = console
const sleep = ms => new Promise(res => setTimeout(res, ms))
const q = [3,5,undefined,7,9,undefined,11,13]
// async because we pretend it's a network call or whatever
const try_pull = async () => {
    const x = q.pop()
    log('pulling', x)
    await sleep(100)
    return x
}
const pull = async () => {
    for (let i = 0; i<3; i++) {
        const next = await try_pull()
        if (next) return next
        log('nothing, sleeping 1s')
        await sleep(1000)
    }
    throw new Error('timed out')
}
const proc = x => console.log('processing', x)
const d = async q => {
  while (true) proc(await pull())
}
log('starting')
const task = d()
log('started')
try {
    await task
} catch (err) {
    log(err)
}
log('finished')
Enter fullscreen mode Exit fullscreen mode
Collapse
davidroffe profile image
davidroffe

Couldn't help but wonder as to why you made the proc function async? I ran this bit of code with and without it, but spotted no real difference. Just something eating away at my curiosity.

Collapse
qm3ster profile image
Mihail Malo

My "bad", it's a carryover from my other, simpler, comment.
There, awaiting proc was the single yield point in the loop, so it did make all the difference. Here there's a second await from the pull inside the loop iteration, so processing can be made sync.
However, and yet again my bad, it seems awaiting a sync value still yields to the event loop as well. So in both examples it is unnecessary.
I'll now edit both comments accordingly.