[Gnash] Question about event handling in swf/flash


From: xxx
Subject: [Gnash] Question about event handling in swf/flash
Date: Thu, 4 Sep 2008 17:41:52 -0700 (PDT)

I am trying to figure out how event handling dispatchers work in flash/.swf.

Specifically, is there a *separate* event handler thread that invokes the 
callback event handler methods or is that done by the main thread, in between 
frame by frame execution ?

I've googled this, and looked at the tamarin source and also at the gnash 
source. Unfortunately, I am not a C++ programmer so it's proven a bit hard to 
follow.

My understanding so far is that there is:

1) There is only one (1) execution thread. No separate event-dispatch thread 
exists in the player. (unlike, say java, where all events are dispatched in the 
awt-event-dispatcher).

2) Events and callbacks (such as with setTimeout) are "queued" and the main 
thread pops events off the queue and invokes them. This is true both for events 
recieved from the operating system (network data, for example) and for things 
like mouseclicks.

3) The main method also invokes code at each "frame". It invokes queued events 
in between frames (or maybe along with them, don't know ?)

Is this understanding by are large true ? This implies that it is possible to 
hang the player entirely by saying "while (true) { }" in an event handler ? 

Reply:

Re: [Gnash] Question about event handling in swf/flash


From: [name deleted for privacy]
Subject: Re: [Gnash] Question about event handling in swf/flash
Date: Sun, 7 Sep 2008 12:01:39 +0200

> I am trying to figure out how event handling dispatchers work in flash/.swf.
> 
> Specifically, is there a *separate* event handler thread that invokes the 
> callback event handler methods or is that done by the main thread, in between 
> frame by frame execution ?

Main thread only.

> My understanding so far is that there is:
> 
> 1) There is only one (1) execution thread. No separate event-dispatch thread 
> exists in the player. (unlike, say java, where all events are dispatched in 
> the awt-event-dispatcher).

Correct.

> 2) Events and callbacks (such as with setTimeout) are "queued" and the main 
> thread pops events off the queue and invokes them. This is true both for 
> events recieved from the operating system (network data, for example) and for 
> things like mouseclicks.

More or less. For network data it's a kind of mix (channels are polled) but 
still the triggers execute in main thread.

> 3) The main method also invokes code at each "frame". It invokes queued 
> events in between frames (or maybe along with them, don't know ?)

User events are invoked immediately, frame events on frame rate boundary.