> I'm trying to find a solution to a bug in firefox (but NOT internet
> explorer) where the parallel execution of the callback function is not
> shielded by the code (prototype's PeriodicExecuter has the same
> problem - their example code *does not work* in firefox (firebug & web
> developer plugin installed). Any comments are appreciated.
Hi,
I was able to finally fiqure out the syntax for passing the options
and do some testing.
I have alot of experience with threaded, sychronization and RTOS
designs, but I'm not familar with DOM thread design, scheduler, etc.
This is my first real exploration here and I can instantly see there
is problem here that conflicts with the scheduler or timer. You can
see it with your code and even with a more basic code like so:
function setCallBack( fn, time ) {
fn();
if (time > 0) return setInterval( fn, time );
}
with two instances of 3 and 6 seconds frequecies:
setCallBack(function() { myCallBack1(); }, 6000);
setCallBack(function() { myCallBack2(); }, 3000);
What happens is a "clash" when the two events are triggered at the
same time, like at the 6 sec mark which is the first time they both
meet. Once that happens, the timer is hosed, i.e, they both now have
the same frequency.
That tells me the DOM timer is singled threaded and you need some kind
of "task sychronization" manager, like a messaging queue which would
manage all your callback scheduling. This task manager would emulate
"concurrency" or parallel execution but it wouldn't be true
concurrency unless DOM was multi-thread and allowed for callback pre-
emptive context switching. So its "Task switcher" and each task must
finish.
Anyway, I need to study DOM thread/scheduler design more, but you can
definitely see you need a task manager here to emulate emulate
concurrency. I would be surprise if there isn't already a JS library
to handle this out there.
--
HLS
