scripts and threads

[cburton400]

I've been scripting for a couple of months now and find that it can be painful. It's not the language or library, but how doing certain things require you to "split" up your routines. Things like doing a scan, getting a message, or reading a notecard. For example, I was writing a script to scan a region. I wanted to move, sensor scan, move, sensor scan, etc. Normally I would do something like:

for(y=0;y<ymax;y=y+inc){
for(x=0;x<xmax;x=x+inc){
llSetPos(<x,y,z>);
//do sensor scan
//wait for the results
//process results
}
}

The only way I've been able to do this in LSL is to split the logic up into separate pieces and handle the looping myself. Add additional complexity if you also use a scan elsewhere in your script.

So, my questions are:

1) Is there some way around the need to split up the routine? Am I just completely missing something?

2) It seems that threads would help this. Is there any reason scripts shouldn't support threads (though I don't have much hope SL will add this feature)?

 

[Dora Gustafson]

I don't think there is anything like what you propose.
LSL is an event based language based on a dialog with the server.
As an example there is no way you can have a sensor() event handler inside a loop like for(.;.;.){}

I can recommend to focus on what you can do with LSL and not what you can't.
It may seem awkward for a long time but it can become natural over time:smileyhappy:

[Ela Talaj]

Your routine is not gonna work anyways, thread or no thread, because it is only good within a 10m square. If your xmax > 10 the object would not be able to return to x=0 after the inner loop completion because llSetPos() only works for 10m distance

As for the rest, the LSL script architecture is no different from any real time program architecture. Software reacts to events happening in the outside world. Events are reported by hardware via what is called interrupts, which is somewhat similar to Unix/Linux signals. Interrupt Service Routines receive interrupts and depending on their type pass control to a proper software part to process. The LSL operates the same way just calls them events, not interrupts. It even takes care of most of the interrupts handling details, like queing, timing, cleanup, etc which are transparent for an LSL scripter.

 

[cburton400]

Dora,

I guess you're right.  I'll just have to accept that in SL it's a scripting language and any limitations that implies. 

I've been using OpenSim to get around this (I can add threads to the compiler since the source code is available) but OpenSim doesn't have all the people SL does and it gets a bit lonely...

 

Ela,

Getting around the 10m limit is rather straight forward: make a list of co-ordinates between the start and end points at 10m intervals and use llSetPrimitiveParams to move.

It's been a while since I've looked at some of this, but I thought that events get queued and when your code finishes and returns control to whatever called it, the system would take an event off the queue and re-calls your script, meaning that your code isn't called until you relenquish control.  An interrupt stops everything and runs it's code and then returns control. 

 

Anyway, thank you both for your responses.  I'll just have to live with it.

 

[Miranda Umino]

You don t need thread for what you want to do .

 

If I ve understood , you want a synchrone execution and not an asynchrone  execution .

So for this , you need to trigger the next event inside the current event itself . Imagine to program recursively.

In your instance , inside  sensor/no_sensor event  , you call a function who will move to the next position and who will call llSensor

 

 

This is an instance of coe

movingSynchrone(vector dest){            while ( llGetPos() != dest )        llSetPos(dest);     llSensor("","",PASSIVE,5.0,PI);   }vector nextIter(){    if ( iteratorCurrent.x >= iteratorEnd.x )    {        if ( iteratorCurrent.y < iteratorEnd.y )        {            iteratorCurrent.x = iteratorBegin.x;            iteratorCurrent.y += iteratorStep.y;        }        else        {        }    }        else    {        iteratorCurrent.x += iteratorStep.x;    }    return iteratorCurrent;    }doJob(vector v){    llOwnerSay("i m working on "+ (string)v);}doJobAndNext(vector v){    doJob(v);     vector v = nextIter();    if ( v != iteratorEnd )        movingSynchrone( v );    else         endProgram();        }endProgram(){    iteratorBegin = ZERO_VECTOR;    llOwnerSay("Program has finished ");}vector iteratorBegin = ZERO_VECTOR;vector iteratorStep = <2,1.5,0>;vector iteratorEnd =  iteratorBegin ;vector iteratorCurrent;default{        touch_start(integer total_number)    {        iteratorBegin += llGetPos();        iteratorEnd = iteratorBegin ;        iteratorEnd.x  += 5 * iteratorStep.x ;        iteratorEnd.y  += 8 * iteratorStep.y ;        iteratorCurrent = iteratorBegin;        doJobAndNext( iteratorCurrent);                    }    sensor(integer n)    {        doJobAndNext( iteratorCurrent);                   }    no_sensor()    {        doJobAndNext( iteratorCurrent);        }    }

 

 Note : for physical moves , you should inside the sensor event call a function who will move your prim. and it s at the moving_end or at_target event who you will call llsensor event

[PeterCanessa Oh]

Multi-threaded applications are even harder to synchronise than asynchronous event-processing.  The main reason they aren't supported though is probably that there aren't multiple cores available to run those separate threads.  Bearing in mind that you can have multiple scripts communicating (separate processes rather than threads) I can think of no advantage to threading at all; it's just another multi-tasking architecture.  The essential issue is whether any operation is blocking or non-blocking for the script it's in.

There IS a way to make asynchronous LSL calls synchronous in-line but it's so awful I can't bring myself to explain it.  I blame Void although I can't really remember who first used it.  The memory is so traumatic I've shut it off.

[therapy!]

[Void Singer]

I heard my name, and the suggestion that I had stretched the bounds of sanity, and I grinned rubbed my hands evilly.

[PeterCanessa Oh]

;-) I refer to polling the object's description.  A truly terrible thing to do to a script.

[Void Singer]

oh I knew which trick you had in mind, I just wasn't gonna repeat it because it's only half sane in limited circumstances.

[Nelson Jenkins]

I can already tell this would be a horrendously bad idea unless you had a reckless disregard for efficiency.

[Ela Talaj]

An interrupt is simply a means to deliver some real world event to the software. Whether they stop everything or are queued or whatever else depends on a specific system architecture. In LSL all events have the same priority and that priority is equal to that of the user code, so they are queued in FIFO and processed when the currently executing user code finishes.

All this has really very little to do with the "language" itself and much to do with a server architecture. To my knowledge the terms "script" came from writing Unix shell programs in the ancient times before Perl Since then the difference between "script" and "language" became kinda blurred. The LSL is a fully blown hi-level object-oriented language with its own compiler and its own advantages and deficiencies. One of them is that it does not have low-level facilities but then neither does Java. I guess it is called  "scripting language" because it is not universal but only runs on specific platforms.

[Ela Talaj]

Guess all hacks think alike I started using polling object description 3 years ago inside tight loops in my first systems because I didn't want to use 500 msec or less timer. I'm still not convinced that polling object description is less efficient than using timers with less than 1sec period and seen no data to convince me.

[Void Singer]

I agree, very useful in some scenarios, for instance it's the method I proposed for on demand reading of landmark data way back on the original forums to work around the llMapDestination touch limit. It's usually overkill for anything that you can sensibly pre read or event chain, of course, so most of the basic stuff dealt with in the forums doesn't need it. I tend to avoid it generally because of the lowered security implied, but it's nice to have when you need it.