--- In flexcoders@yahoogroups.com, "Ralf Bokelberg" <[EMAIL PROTECTED]> wrote: > > Beeing able to dispatch events while we are dispatching an event is > the expected behaviour. ActionScript doesn't have threads, so it's > threadsafe per definition. In other words, it never happens, that an > event interrupts a running method. If you dispatch an event while you > are in another event handler, the new event is completely handled > before the remaining handlers of the initial event are called. It's > just simple method calls. > > 1 dispatch event 1 > 2 handle event 1 > 3 dispatch event 2 > 4 handle event 2 > 5 handle event 2 > 6 handle event 1 > 7 handle event 1 > > So what is the exact problem you see? An exception in line 2 doesn't > stop the rest of the handling? > > Cheers, > Ralf. > > On 11/4/06, ncr100 [EMAIL PROTECTED] wrote: > > This is a complex one. > > > > Summary: > > > > I believe I'm not confused with try/catch, but am surprised that the > > EventDispatcher assumes our code is reentrant. Reentrant like the > > EventDispatcher is dispatching a system Event in the middle of me > > handling other events. So we're vulnerable to reentrant callbacks > > when we call EventDispatcher.dispatchEvent. > > > > Details: > > > > Normally when an null dereference happens an Error is propagated up > > the call stack to a catch handler. > > > > The bug is this: if in the middle of this call stack there happens to > > be an EventDispatcher.dispatchEvent call and the null pointer happens > > somewhere inside one of the listeners, then the Flash VM runtime > > thingy / implementation of dispatchEvent() itself seems to catch & > > handle the Error, and takes the opportunity to dispatch a pending > > Events. In my case I've seen a ProgressEvent.SOCKET_DATA being > > dispatched because my server pumped out some data to me really > > quickly, though I assume any pending Event could be dispatched. > > > > This really causes havoc because our methods aren't reentrant; flash > > isn't multithreaded afaik and we don't think we have to write > > everything thread-safe. > > > > Here's an illustration I will walk through. At the start of the stack > > our DTVSocket.onSocketConnect listens for an > > ProgressEvent.SOCKET_DATA, and just got one. Notice for now the > > EventDispatcher [no source] in the middle of the stack trace. Capping > > off the stack trace, see our TextUtil.setText method ... it is doing > > something bad, and has just triggered a null pointer exception! > > > > dtv.util::TextUtil$/setText (BANG! null pointer exception) > > MarbachViewer/MarbachViewer::createChannelCanvas > > MarbachViewer/MarbachViewer::subscribeToChannel > > MarbachViewer/MarbachViewer::onConnected > > flash.events::EventDispatcher/flash.events:EventDispatcher::dispatchEven\ tFunction > > [no source] > > flash.events::EventDispatcher/dispatchEvent [no source] > > dtv.util::DTVSocket/dtv.util:DTVSocket::dispatchOnConnectedEvent > > dtv.util::DTVSocket/dtv.util:DTVSocket::onReceivedSessionTicket > > Function/http://adobe.com/AS3/2006/builtin::call [no source] > > dtv.util::DTVSocket/dtv.util:DTVSocket::onJSON > > dtv.util::DTVSocket/dtv.util:DTVSocket::onData > > dtv.util::DTVSocket/dtv.util:DTVSocket::onSocketData > > > > > > Now notice in this second shorter trace the stack has been unwound up > > to the dispatchEvent, but no further. onSocketData was just passed a > > second, new ProgressEvent.SOCKET_DATA. It must be that > > EventDispatcher.dispatchEvent caught my setText's null pointer > > exception and dispatched some additional socket data to my > > ProgressEvent.SOCKET_DATA listener. onSocketData is not thread safe. > > and bad stuff will happen very soon after in our code. > > > > dtv.util::DTVSocket/dtv.util:DTVSocket::onSocketData (WHOA! Not good) > > flash.events::EventDispatcher/flash.events:EventDispatcher::dispatchEven\ tFunction > > [no source] > > flash.events::EventDispatcher/dispatchEvent [no source] > > dtv.util::DTVSocket/dtv.util:DTVSocket::dispatchOnConnectedEvent > > dtv.util::DTVSocket/dtv.util:DTVSocket::onReceivedSessionTicket > > Function/http://adobe.com/AS3/2006/builtin::call [no source] > > dtv.util::DTVSocket/dtv.util:DTVSocket::onJSON > > dtv.util::DTVSocket/dtv.util:DTVSocket::onData > > dtv.util::DTVSocket/dtv.util:DTVSocket::onSocketData > > > > > > So the deal is this: Beware of event listener entry-points being > > called in a reentrant fashion if your app is handling an exception. > > Kind of like someone hitting you when you're down, flash is asking for > > your app to do stuff when it's crippled. > > > > A solution is to wrap the guts of all entry points in try/catch > > handlers. Or maybe only for high-frequency entry points. > > > > I looked thru these links for insight, perhaps hints indicating this > > kind of behavior but didn't find it: > > http://livedocs.macromedia.com/flex/2/docs/wwhelp/wwhimpl/js/html/wwhelp\ .htm?href=00001890.html > > http://livedocs.macromedia.com/flex/2/langref/statements.html#try..catch\ ..finally > > > > Happy November! > > Nick > > > > > > > > > > -- > > Flexcoders Mailing List > > FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt > > Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com > > Yahoo! Groups Links > > > > > > > > > > > > > -- > Ralf Bokelberg [EMAIL PROTECTED] > Flex & Flash Consultant based in Cologne/Germany >
-- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/flexcoders/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
