Why do event handlers wait for loops?

In LSL, why do event handlers wait for loops to complete? If LSL is going to handle events, shouldnt events be handled -when- they happen, not later?

I imagine that is to reduce the complexity. i.e. handling events at the end of each function call when the state of the script is clear, instead of having to attempt thread-safe code that synchronizes all the script globals (oh my, just think about that makes me feel all faint)....

In OSMP creating a virtual machine and calling an event is basically a call to an external library, LUA for OSMP.

The VM's in LUA are able to handle multithreading, Azelda has made it so only one function can be running. The VM can report if it's busy and events are queued in this case.

// main loop
// check for events, add them to a queue
// loop through queued events and send them to free vm's

VM's are created in separate threads. If a VM is busy, in loop for instance, the event is still in the queue and the script engine will try to deliver the event the next time around.

Azelda could explain it better, he wrote everything I'm trying to describe here.

If you called a timer event faster than it was able to complete, that could cause problems. It would be very hard, to sync globals in LUA. I'm not even sure if LUA will allows for creating instances of the same VM. The lua stack would have problems I'm guessing.

I don't think SL uses the LUA engine, but it sounds like are similar.

Fortunately, you can use a second script buffer to break the loop.

For example. Script number one:

default
{
     state_entry()
     { 
          llSetStatus(STATUS_PHANTOM,TRUE);
          while(llGetStatus(STATUS_PHANTOM))
          {
          }
     }
}

Script two could break the loop by doing this:

default
{
      touch_start(integer total_number)
      {
           llSetStatus(STATUS_PHANTOM,FALSE);
      }
}

Multiple buffer scripting is fun!

Good idea!

Fixed the text. Don't ask me how that one happened.