JavaScript同步Ajax请求特质

Question

I'd like to preface this with an apology if I'm doing things in a "weird" way, as I'm primarily a C developer and am solving this AJAX problem the way I would in C.

I have a script that will be connecting to a "push server" that waits until a message is available, then sends only that one message and breaks the connection. The client must then reestablish the connection to listen for future messages.

I tried to do this by implementing a synchronous AJAX call within an asynchronous callback, and it works except it appears the DOM (maybe? I'm showing my ignorance of JS here) will block until all calls are complete.

I do not know how to do it with purely asynchronous calls as I do not want to end up exhausting the stack by having a callback calling a callback each time.

This is the code:

        $.ajax({
            url: './recoverDevice',
            data: JSON.stringify(requestData),
            dataType: 'json',
            type: 'POST',
            success: function(j)
            {
                console.log(j);
                if (j.success)
                {
                    //Indefinitely listen for push messages from the server

                    var loopMore = true;
                    while(loopMore)
                    {
                        $.ajax({
                            async: false,
                            url: './getPendingMessage',
                            dataType: 'json',
                            type: 'POST',
                            success: function(j)
                            {
                                //alert(j.message);
                                $("#progressBox").append("<li>" + j.message + "</li>");
                                loopMore = !j.complete;
                            }
                        });
                    }

                }
                else
                {
                    $("#errorBox").show();
                    $("#errorBox").text(j.errorMessage);
                }
            }
        });

Now, logically, this code should work. Within an asynchronous function, I loop over a synchronous JS call, each time I get a message I will append it to the DOM, and only when the server tells me there will be no more messages do I exit the loop, ending the asynchronous thread and completing the task.

The problem is that the DOM access appears to be all coalesced once all messages have been received. ie the appends only happen once all messages have been received and the asynchronous thread has exited.

The commented out alert was a test - it works perfectly . I get a message box after each and every notification, and it pauses correctly until the next message (with the rest of the code as-is).

I'm guessing this is my browser (Chrome) doing some magic to protect against race conditions by not allowing DOM manipulation until the asynchronous thread has exited? Or am I way off the mark and barking up the wrong tree here?

Getting rid of the loop and setting async to true makes the first message be received properly (no problems there), but obviously no messages thereafter.

Obviously I could do something like this:

function GetMessage()
{
    $.ajax({
        async: true,
        url: './getPendingMessage',
        dataType: 'json',
        type: 'POST',
        success: function(j)
        {
            $("#progressBox").append("<li>" + j.message + "</li>");
            if (!j.complete)
            {
                GetMessage();
            }
        }
    });
}

But that would result in a stack overflow over time (no?).

An obvious solution would be to use asynchronous calls here too, but to signal a while loop to pause and continue with new calls via some sort of synchronization primitives, but appears that JS does not have signalling primitives?

Answer 1

Figured this one out - I don't know why I didn't see this before but my latter code fragment works perfectly. I didn't realize it at the time of posting, but it can't overflow the stack because each time it runs it launches an async call and exits - so the stack frame is never more than 2 or 3 deep. The asynchronous calls are managed externally and won't be on the stack, so each time it starts over.

I'd still appreciate any input on why the first method (synchronous code in asynchronous call) didn't/wouldn't work.