1  |   Order by index

Feb 27, 2000, 8:14am

Just need a quick yes/no answer. Is the SDK for Active Worlds thread-safe?

P.S. Not like I care that much, since I mainly use Visual BASIC for
programming bots. However while doing some thread programming in Visual
C/C++ the other day, I got to thinking about the AW SDK.

P.P.S. If the answer is more complex than just yes/no, feel free to
elaborate. :o)

Feb 27, 2000, 10:32am

[View Quote] No ;)

--
Mauz
http://tnlc.com/mauz/

Mar 1, 2000, 6:07pm

[View Quote] More on threads...

Say I have a mother program that spawns children bots as a certain function
is executed external to activeworlds (say on a webpage). Now these
children bots are threads within that program. There is no threading going
on within these children bots, they are just activeworld bots that are
threads themselves...

now I can't see the activeworlds sdk having any problems with this, but
perhaps if someone does, then could they say what problems could be
encountered with this threading and the sdk?

Omar

Mar 1, 2000, 6:42pm

It will have lots of problems with that.

The API requires that you use aw_instance to select the bot and then make
the call required. In a multi threaded process there is no guarantee that
once the aw_instance is called that another bot thread will not cut in and
perform some action.

Your only solution is to use fork or the windows equivalent
Win32::CreateProcess. Sorry not a big window chappy.

[View Quote]

Mar 14, 2000, 1:14am

A classic case of a race condition :-)

From what I understand from the docs there can be only one active instance,
and the active instance is set either by you or by the SDK when an event
happens. Now when you're only doing stuff and not listening to events, you can
just set the current instance, have that instance do its stuff, and on to the
next.

When you're listening to events, and make synchronous calls or do the aw_wait
thing, the SDK can half way through just pop in and change the current
instance. So I guess the trick here is to only call aw_wait and do synchronous
calls when you aren't doing anything else. Which is easier said than done in a
multithreaded event-driven application :-) (Although I am going to do it...
Yikes!)

Now the part I'm not too sure about is this, but here's my guess:
the SDK, being a single threaded process, processes events serially and then
sets the current instance and dispatches the event to its associated listener
in a synchronous manner. So theoretically, there should be no way one event
can mess with the current instance while another event is being processed.

Schattenjager

[View Quote] > It will have lots of problems with that.
>
> The API requires that you use aw_instance to select the bot and then make
> the call required. In a multi threaded process there is no guarantee that
> once the aw_instance is called that another bot thread will not cut in and
> perform some action.
>
> Your only solution is to use fork or the windows equivalent
> Win32::CreateProcess. Sorry not a big window chappy.
>
[View Quote]

1  |   Order by index