Thanks for your reply.
Joost Diepenmaat wrote:
>
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.