ThreadBoard ArchivesSite FeaturesActiveworlds SupportHistoric Archives |
synchronizing problem (Sdk)
synchronizing problem // Sdkwalter knupeDec 22, 1998, 9:34pm
Roland,
i trying to implent user-level security into my bot, so i had it ask for the citizen number of a avatar in response to a request. it used aw_citizen_by_name(). the problem is that aw_citizen_by_name does an internal aw_wait() while waiting for the server, which in turn calls my callback functions for any events, and that causes other code in my bot to get executed, and changing state inside... e.g. the state about the person talking to the bot... after that inner request is served, and my callback function returns, it returns back to the callback function, which returns into aw_wait(), which finaly returns the aw_citizen_by_name() call. in that function i do have the information requested, but i am unaware that in the meantime a lot of other eventhandling and state changing took place.... my point is here, that we need callback functions for ALL aw.dll functions which might block on an aw_wait() call. and it would be nice to be able to disable event dispatching for the period of a function call. the current way is similar to windows message dispatching. code invoked in response to a windows message which opens a messagebox invokes internal message dispatching again, and might be re-called while still in the function.. message-based preemptive tasking, that is :) for now i am going to disable userlevel auth, but i think i have to redo my complete event and callback dispatching.. i have to store everything on a FIFO list and work on that from the top level aw_wait() loop only.. which disables all benefit gained by a callback mechanism... Walter Walter roland vilettDec 23, 1998, 4:33pm
aw_citizen_by_name() does have a callback: AW_CALLBACK_CITIZEN_ATTRIBUTES.
Every single method that could potentially block in aw_wait() has a callback. The corresponding callbacks for the various methods are not clearly documented and I apologize for that. Yet another thing for my growing list of doc improvements... -Roland [View Quote] canopusJan 27, 1999, 10:00pm
I'm working on an object-oriented platform for Delphi programmers, one that will
use avatar, chat, citizen, and other objects and will hide a lot of aw details inside object methods. From reading this thread, and also the thread below about citizen lookup confusion, I have come to believe that it is dangerous to use synchronous calls (aw_citizen_attributes_by_name, aw_object_add, aw_query, aw_enter, etc.) in programs that also contain event handlers and asynchronous callbacks. The danger occurs because the synchronous calls do an implicit aw_wait, and during that aw_wait, any event handler or asynchronous callback might be called. This is what the documentation on Events warns us about, namely that "events can be triggered at any time the SDK is active...except for those methods that are documented to 'return immediately'." The methods that are documented to "return immediately" are the ones that can and do have callbacks installed (the ones that can be dangerous when synchronous, but are tamed when divided into an earlier part and an asynchronous part). My question is, are there other methods that "return immediately"? Specifically, will events and asynchronous callbacks occur during the course of methods like aw_state_change, aw_say, aw_session, and aw_whisper? [View Quote] > Roland, > > i trying to implent user-level security into my bot, so i had it ask for the > citizen number of a avatar in response to a request. it used > aw_citizen_by_name(). > > the problem is that aw_citizen_by_name does an internal aw_wait() while > waiting for the server, which in turn calls my callback functions for any > events, and that causes other code in my bot to get executed, and changing > state inside... e.g. the state about the person talking to the bot... > > after that inner request is served, and my callback function returns, it > returns back to the callback function, which returns into aw_wait(), which > finaly returns the aw_citizen_by_name() call. in that function i do have the > information requested, but i am unaware that in the meantime a lot of other > eventhandling and state changing took place.... > > my point is here, that we need callback functions for ALL aw.dll functions > which might block on an aw_wait() call. and it would be nice to be able to > disable event dispatching for the period of a function call. > > the current way is similar to windows message dispatching. code invoked in > response to a windows message which opens a messagebox invokes internal > message dispatching again, and might be re-called while still in the > function.. message-based preemptive tasking, that is :) > > for now i am going to disable userlevel auth, but i think i have to redo my > complete event and callback dispatching.. i have to store everything on a > FIFO list and work on that from the top level aw_wait() loop only.. which > disables all benefit gained by a callback mechanism... > > Walter > > Walter |