Collisions & priorities: xmlHttpRequest and setInterval

[RgeeK]

From my newbie perspective I understand that Javascript is a single
threaded environment and so interrupt-driven events are going to be
somewhat challenging.

But, I have an issue which seems to be to be a collision between a
periodic drawing event (based on "setInterval") and a periodic http
request based on the "xmlHttpRequest.onreadystatechange" listener.

I assume my interval timeout, and the operations associated with that
occasionally make me miss my http reply.

Two questions
a) given that one of these (the receive) is more important to me than
the other (the setInterval) can I set priorities in some way?

b) is there some other good method for handling such interrupt
collisions? I'm hoping to avoid the whole process of associating
receives with the requests that spawned them, and doing re-transmission
requests etc, A time-out is prudent no doubt, but I'd like to give my
receives a fighting chance.

Thanks for any thoughts...

Ross.

 

[Joost Diepenmaat]

From my newbie perspective I understand that Javascript is a single
threaded environment and so interrupt-driven events are going to be
somewhat challenging.

It's a good thing that javascript (at least in browsers) doesn't need
to handle interrupts, then.

But, I have an issue which seems to be to be a collision between a
periodic drawing event (based on "setInterval") and a periodic http
request based on the "xmlHttpRequest.onreadystatechange" listener.

I assume my interval timeout, and the operations associated with that
occasionally make me miss my http reply.

What do you base that assumption on?

Two questions
a) given that one of these (the receive) is more important to me than
the other (the setInterval) can I set priorities in some way?

No. At least not in any portable way that I know of.

b) is there some other good method for handling such interrupt
collisions?

Neither of those are interrupts in any sense that I know of. It's just
bog-standard event handling. Meaning; one event is handled, then the
other event is handled. From a javascript point of view, events
*never* occur at the same time.

What will happen if you starve the CPU by running massive amounts of
long-running events is not really defined, though.

I'm hoping to avoid the whole process of associating receives with
the requests that spawned them, and doing re-transmission requests
etc, A time-out is prudent no doubt, but I'd like to give my
receives a fighting chance.

You may want to reduce the work you do in any single event
handler. And also maybe increase the interval for your setInterval
events.

 

[Jorge]

From my newbie perspective I understand that Javascript is a single
threaded environment and so interrupt-driven events are going to be
somewhat challenging.

But, I have an issue which seems to be to be a collision between a
periodic drawing event (based on "setInterval") and a periodic http
request based on the "xmlHttpRequest.onreadystatechange" listener.

I assume my interval timeout, and the operations associated with that
occasionally make me miss my http reply.

Two questions
a) given that one of these (the receive) is more important to me than
the other (the setInterval) can I set priorities in some way?

b) is there some other good method for handling such interrupt
collisions? I'm hoping to avoid the whole process of associating
receives with the requests that spawned them, and doing re-transmission
requests etc, A time-out is prudent no doubt, but I'd like to give my
receives a fighting chance.

Thanks for any thoughts...

Ross.

Ross,

This http://tinyurl.com/5sx3jr keeps posting XHRs in a loop (25 at a
time) while a setTimeout(f, 1) updates a counter.

Safari, Opera and FF dispatch the events in a different order, but no
XHR seems to get lost in hyperspace...

--Jorge.

 

[RgeeK]

Thanks for your reply.

What do you base that assumption on?

This is based on some behaviour of app that seems to be missing receive
events in response to my server requests. The missed responses increase
in frequency as I make the interval smaller in the other task.

I'm new enough to JS that I don't pretend to know how the event handling
works, but the idea that one might be pre-empting the other made me
think it was behaving more like prioritized interrupts.

Neither of those are interrupts in any sense that I know of. It's just
bog-standard event handling. Meaning; one event is handled, then the
other event is handled. From a javascript point of view, events
*never* occur at the same time.

That's reassuring, so I will certainly dig into this further to see if I
can get around it. I guess though that the priority issue is still a
central one as I think about this. If my interval driven code runs and
takes CPU attention away from servicing the arriving httpresponse, I
suppose I could conceivably miss the data when I finally get the chance
to go service that http data-ready event? Perhaps the buffers are
flushed in preparation for the next arrival before I can get at the data?

What will happen if you starve the CPU by running massive amounts of
long-running events is not really defined, though.

My events aren't very CPU intensive - so I don't expect to be really
hammering it.

You may want to reduce the work you do in any single event
handler. And also maybe increase the interval for your setInterval
events.

I know the interval increase works - but given that I'm driving some
graphics, lengthening the interval degrades the visuals. However,
that's what made me concerned about missed receive events: with
lengthened intervals I can account for all the receive events. With
shorter intervals I miss several, up to the point where intervals in the
10ms range ( I assume those are mS units) mean I don't manage to process
any receives at all.

Thanks for the comments!

Ross.

 

[Joost Diepenmaat]

Thanks for your reply.


This is based on some behaviour of app that seems to be missing
receive events in response to my server requests. The missed
responses increase in frequency as I make the interval smaller in the
other task.

What kind of events are we talking about here? Servers don't send out
requests. Browsers do. At least if your using XmlHTTPRequest You
should *at least* get a readystatechange event when the document is
fully loaded (readyState == 4). I'm not sure that any of the other
state changes are reliable, though (especially if your browser is
caching the responses).

My events aren't very CPU intensive - so I don't expect to be really
hammering it.

Are you sure? Animations can take up a lot of CPU time, even if the JS
code does hardly anything.

One thing you could try is instead of using setInterval, re-register
your event using setTimeout at the end. that should ensure you've got
some time left to handle any other events in between even if your
timed events take longer than the interval:

function timerHandler() {
// do your animation here

// call again in 50 ms
setTimeout(timerHandler,50);
}
timerHandler();

 

[Jorge]

This is based on some behaviour of app that seems to be missing receive
events in response to my server requests.  The missed responses increase
in frequency as I make the interval smaller in the other task.

(...)

If my interval driven code runs and
takes CPU attention away from servicing the arriving httpresponse, I
suppose I could conceivably miss the data when I finally get the chance
to go service that http data-ready event?  Perhaps the buffers are
flushed in preparation for the next arrival before I can get at the data?

(..)

I know the interval increase works - but given that I'm driving some
graphics, lengthening the interval degrades the visuals.  However,
that's what made me concerned about missed receive events: with
lengthened intervals I can account for all the receive events. With
shorter intervals I miss several, up to the point where intervals in the
10ms range ( I assume those are mS units) mean I don't manage to process
any receives at all.

Even under heavy load (a setInterval(f, 0), being f() a cpu-intensice
time-waster procedure), all the browsers I test manage to dispatch
properly to all the (25 simultaneous) posted XHR's objects' callbacks,
and never miss a single one. I'd bet the problem lies in your code,
not in the browsers'.

Test it yourself : http://tinyurl.com/5sx3jr

--Jorge.