1  |   Order by index

Dec 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

Dec 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]

Jan 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

1  |   Order by index