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.
For further actions, you may consider blocking this person and/or reporting abuse
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.