Concurrency in LSL scripts?

I've got a box that gives answers to preset questions. Basically, there's a dialog in the touch event. The avatar selects a button. The listen event provides infomation based on the selection.

If a dozen avatars hit the box at the exact same time, does the dialog and listen event handle concurrency?

If it does, then is it possible to manage the state for each avatar at the box? I'm assuming global variables will be overwritten each time an avatar touches.

I was thinking about creating a state queue using a list, but there doesn't seem to be a bullet-proof way to lock it when new data is being written...

External databases through http are one solution, but that adds a lot of variablility - and the whole thing can crash if there are any internet glitches.

Any thoguhts on this?

There is really no concurrency handling provided by LSL, since there is only one instance ever running of a given script within an object. Let's say your script is handling some listen event, and during that time 4 avatars touch the object simultaneously. The listen event runs to completion, then when the script processes the "touch" event, the value of the integer returned in the "touch" event parameter will be 3, and the script is responsible for maintaining whatever context it needs to process the touch events separately for the 4 avatars.

And yes, this does lead to global sets of lists, or strided lists, for context that must span multiple events.

I'm not sure if that addresses your question, but it's the best I can do before coffee
.

Yeah, it's messy. But if every touch isn't critical, the touch event handler can deal with llDetected*(0) only, and move to a state without any touch events to do all the dialog processing. In theory, you could keep a list of all the other touchers and handle them, too, but if it's that important never to miss a touch, this isn't a viable approach anyway because touches during the "touchless" state will not be queued. And in that case, the script would have to just process lists of asynchronous touches, as Nika explained.

Unless it is important for some reason to keep track of who touched the object to begin with, you can just keep the dialog listen open on a specific channel (I recommend picking a large random negative one). When agents touch the object, give them the dialog and forget about them. When you get a message on the dialog channel, deal with that response. Just don't filter the dialog listen on the resident's key.

For example (not compiled or tested):

integer DIALOG_CHANNEL = -1384723094;
string PROMPT = "Choose a color";
list CHOICES = [ "red", "green", "blue" ];

default
{
    state_entry()
    {
        llListen(DIALOG_CHANNEL, "", NULL_KEY, "");
    }

    touch_start(integer nDetected)
    {
        integer i;
        for (i = 0; i < nDetected; ++i)
        {
            llDialog(llDetectedKey(i), PROMPT, CHOICES, DIALOG_CHANNEL);
        }
    }

    listen(integer channel, string name, key id, string message)
    {
        if (channel == DIALOG_CHANNEL)
        {
            llInstantMessage(
                id,
                "Well "+name+", I see you picked "+message+
                ".  Good choice!  That happens to be my favorite color too.");
        }
    }
}

In SciFi, the trouble usually starts when the machines learn how to lie. Careful...

Good point. But I thought kiss-ass behavior was easier than forming a real opinion. At least this machine has no willpower...so far as we know....

I haven't tried this, but you could use multiple scripts in the same object.

When the touch event occurs, the current script would enter a state without a touch handler and then issue the llDialog on a specific channel unique to itself. When it times out or gets an answer, it returns to it's touch-active state.

You should, therefore, be able to handle as many different unique touch/dialog events as you have scripts.

(I haven't actually tried this whoever, so who knows if it would behave as expected).


Another method would be to rez a temp object which would issue and collect the llDialog question and then do whatever.

The alternative is keeping track of lists of users... which, if there are enough people at once could consume enough stack space to crash your script! =)

I'm confused, OP just wants to pop a dialog and respond to the specific av from those dialogs.... that doesn't seem hard.

list gLstColors = ["Grey", "Red", "Green", "Blue"];
list gLstCodes = ["<0.5, 0.5, 0.5>", "<1.0, 0.0, 0.0>", "<0.0, 1.0, 0.0>", "<0.0, 0.0, 1.0>"];

default{
  state_entry(){
    llListen( -42, "", "", "" );
  }

  touch_start( integer vIntTouched ){
    do{
      --vIntTouched;
      llDialog( llDetectedKey( vIntTouched ),
                "Hello " + llDetectedName( vIntTouched ) + ", Pick a color"
                gListColors,
                -42 );
    }while (vIntTouched);
  }

  listen( integer vIntChannel, string vStrName, key vKeySpeaker, string vStringHeard ){
    integer vIntIndex = llListFindList( gLstColors, (list)vStrHeard );
    if (~vIntIndex){
      llInstantMessage( vKeySpeaker,
                        vStrName + ", the color code is " + llList2String( gLstCodes, vIntIndex ) );
    }
  }
}