6

So if you’re awaiting a promise and the async function returning the promise calls another async function and doesn’t await it could this counterintuitively cause the whole thing to freeZe ?

Comments
  • 1
    I could write tests for all this crap but of course there is no time
  • 0
    they will all wait for each other to resolve or reject then it cascades down........, I dont know the word for it
  • 1
    But like inside one of the asyncs I’m not awaiting a call to another async and adding an await seemed to allow the code to progress after a long pause for some unknown reason

    I know how I supposed to work but it’s not doing that
  • 1
    if you mean

    const f = async () => {
    asyncFunc();
    }

    await f();

    Then asyncFunc() will get executed but it won't be awaited/blocking (you could add a .then() to it too get the return value)
  • 2
    @pythonPlusPlus yes that is about right but add another layer and if don’t await the innermost function it freezes sometimes
  • 0
    @killames Maybe a simple example would help me understand. I am wondering how it can freeze
  • 1
    Async eventhandler()
    {
    Await asyncfunction()
    {
    Asyncfunctionthatdoesnetworkcall()
    }
    }

    //pseudocode

    @pythonPlusPlus
  • 0
    @killames The inner most call without await should not be blocking. No await, no blocking. The only way for it to freeze is to have a computationally intense task right away (while (true) {}), that will block.
  • 1
    @pythonPlusPlus what I’m saying is there are times the async code never returns it fires one part and freezes

    It’s not standard behavior
  • 0
    @killames have you considered you might have a long running micro task that is holding up execution of future macro tasks and therefore freezing the app?

    If you look at a list of what code causes micro Vs macro and compare your script you might see something. Blocked event loop.
  • 0
    @Crost I fixed this by taking the code that does the network op and defining the then and catch calls

    And then adding a timer to manage these and in the then code adding then back to the main queue already being handled

    And now it works blazing fast

    Literally the only difference is one last await level per item

    I think await adds some significant overhead that it shouldn’t
  • 0
    @Crost that’s my gut feeling anyway
    The more levels of async you add with awaits in them the more likely something will bungle that shouldn’t

    Doesn’t the os usually provide the threading mechanism ?
  • 0
    @killames it's all single threaded. The engine achieves async using what amounts to a fancy loop.
  • 0
    @Crost I know I know but it seems that the one op was freezing because of the extra nesting
Add Comment