Do you have a test case for that event sending failure when created at init? Was it also only in IE, or in IE and Firefox both?
On 8/31/06,
Max Carlson <[EMAIL PROTECTED]> wrote:
I was seeing some bizarro behavior related to LPP-2435 where an event
registered at class init time fails to fire later when
eventname.sendEvent is used. If there's a problem with the event
system, it might help explain this...
-Max
P T Withington wrote:
> How do we explain the erroneous behavior in the profiler then? I'm open
> to other theories.
>
> Jim, what is the tech list you suggested we ask on?
>
> On 2006-08-30, at 15:45 EDT, Henry Minsky wrote:
>
>> Well, the test below does not show the main loop being interrupted by the
>> timer process; it shows the
>> reverse actually, the timer process does not seem to run while the
>> main loop
>> is executing.
>>
>> I have a blinking square hooked up to setInterval at 1/30 second.
>> (note in
>> Firefox it blinks at 30 Hz, in IE
>> it blinks about 3 Hz)
>>
>>
>> When you click on the big square it starts a main busy waiting loop.
>> While
>> that is running, the blinking timer square
>> appears to stop blinking. I don't know exactly when the browser
>> decides to
>> do a screen update , but this looks like
>> the main loop triggered by a mouse click will run exclusively till done.
>>
>> <canvas width="1000" height="500">
>> <view id="box" width="100" height="100" bgcolor="#cccccc"
>> >>> <view id="box2" width="20" height="20" x="150" bgcolor="#cccccc" />
>>
>> <text id="console" y="120"/>
>>
>> <script>
>> <![CDATA[
>>
>> function main () {
>> console.setText ('starting main loop');
>> box.setBGColor(0x0000ff); // blue, start
>> for(var i = 0; i < 800000; i++) {
>> if (foo.bar != 259) {
>> box.setBGColor (0xff0000); // RED, bug found
>> return;
>> }
>> }
>> box.setBGColor(0x00ff00); // green, OK
>> console.setText('done with main loop');
>> }
>>
>> foo = {bar: 259};
>>
>>
>> flag = true;
>> function frob () {
>> if (flag) {
>> box2.setBGColor(0xff0000);
>> } else {
>> box2.setBGColor(0x00ff00);
>> }
>> flag = !flag;
>> foo.bar = null;
>> for (var k = 0; k < 100000; k++) { foo.bar = null; }
>> foo.bar = 259;
>> }
>>
>> setInterval(frob, 33)
>>
>>
>> ]]>
>> </script>
>>
>>
>>
>>
>> </canvas>
>>
>>
>>
>> On 8/30/06, P T Withington <[EMAIL PROTECTED]> wrote:
>>>
>>> I think that is what we are going to have to do, if this turns out to
>>> be true. Henry is writing a test case, but if it is true that a
>>> setInterval call can run asynchronously with some other (long-
>>> running) event code (say from a mouse-click), then we basically need
>>> to write an 'event kernel' that dispatches the events from the
>>> browser serially, something like:
>>>
>>> when an event comes in
>>> put it on a queue
>>> if events are being processed already, return; else
>>> note events are being processed
>>> while there are events on the queue
>>> do the next event
>>> done
>>> note events are not being processed
>>>
>>> With a suitably constructed monitor to ensure that the notes and
>>> queue are atomically updated. Which is a little tricky since there
>>> is no read-modify-write primitive in _javascript_, so you have to play
>>> some games with multiple reads and single writes of flags for each
>>> possible event.
>>>
>>> On 2006-08-30, at 14:46 EDT, Adam Wolff wrote:
>>>
>>> > could we just mutex lock any interrupt calls? I don't think we
>>> > should go
>>> > down the path of trying to handle concurrency.
>>> >
>>> > A
>>> >
>>> >
>>> > On Aug 29, P T Withington wrote:
>>> >
>>> >> Henry and I have some empirical evidence that we have a problem in
>>> >> the LFC.
>>> >> After porting the profiler to DHTML, we both noticed that we got
>>> >> weird errors
>>> >> when running the Profiler.dump task in the 'idle loop'. The best
>>> >> explanation
>>> >> we can come up with is that `setInterval` may invoke your callback
>>> >> at any
>>> >> time, including when the application is actively executing
>>> >> _javascript_.
>>> >>
>>> >> This is a big departure from the SWF idle loop, which
>>> >> (purportedly) only runs
>>> >> your callback when there is nothing else going on.
>>> >>
>>> >> There is also evidence on the web (google '_javascript_ mutual
>>> >> exclusion') that
>>> >> XMLHttpRequest callbacks occur asynchronously and may 'interrupt'
>>> >> your main
>>> >> code path.
>>> >>
>>> >> What's the big deal?
>>> >>
>>> >> Well, at least in the case of the Profiler, there is a shared data
>>> >> structure
>>> >> between the profiling annotations and the background dumper. If
>>> >> these really
>>> >> can operate asynchronously to each other, we need a mutual
>>> >> exclusion mechanism
>>> >> to control access to the data structure or it may be corrupted
>>> >> (which is what
>>> >> Henry and I were seeing).
>>> >>
>>> >> If our Loader code is similarly sharing a data structure between the
>>> >> application code and asynchronous callbacks without any mutual
>>> >> exclusion
>>> >> mechanism, it could explain some of the vagaries we have seen in
>>> >> data-driven
>>> >> applications.
>>> >>
>>> >> The trouble with race conditions is that they are seldom repeatable.
>>>
>>>
>>
>>
>> --Henry Minsky
>> Software Architect
>> [EMAIL PROTECTED]
>
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
_______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
