1  |   Order by default

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 default