const{log}=consoleconstsleep=ms=>newPromise(res=>setTimeout(res,ms))constq=[3,5,undefined,7,9,undefined,11,13]// async because we pretend it's a network call or whateverconsttry_pull=async()=>{constx=q.pop()log('pulling',x)awaitsleep(100)returnx}constpull=async()=>{for(leti=0;i<3;i++){constnext=awaittry_pull()if(next)returnnextlog('nothing, sleeping 1s')awaitsleep(1000)}thrownewError('timed out')}constproc=x=>console.log('processing',x)constd=asyncq=>{while(true)proc(awaitpull())}log('starting')consttask=d()log('started')try{awaittask}catch(err){log(err)}log('finished')
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.
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.
Log in to continue
We're a place where coders share, stay up-to-date and grow their careers.
With rescheduling when empty, consider:
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.
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 thepull
inside the loop iteration, so processing can be made sync.However, and yet again my bad, it seems
await
ing 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.