How long do scripts continue execution after deleting themselves

Apparently deleting a script continues to execute after deleting itself. I suppose a deletion request is queued and is not blocking. My questions are (1) Is this a bug? and (2) how long can it go on, if the sim is laggy, for instance?

Here is an illustrative script and some results of successive drops into a default cube. Note the last instance where the order of messages is wrong! Is that normal? Or is it a result of the deletion?
----------------------------------------------------------------------
default
{
state_entry()
{
//llSay(0, "Hello, Avatar!";
llRemoveInventory(llGetScriptName());
llSay(0, "1";
llSay(0, "2";
llSay(0, "3";
llSay(0, "4";
llSay(0, "5";
llSay(0, "6";
llSay(0, "7";
llSay(0, "8";
llSay(0, "9";
llSay(0, "10";
llSay(0, "11";
llSay(0, "12";
}

touch_start(integer total_number)
{
llSay(0, "Touched.";
}
}
---------------------------------------------------
[18:21] Object: 1
[18:21] Object: 2
[18:21] Object: 3
----------------------
[18:21] Object: 1
[18:21] Object: 2
----------------------
[18:21] Object: 1
[18:21] Object: 2
[18:21] Object: 3
----------------------
[18:21] Object: 1
[18:21] Object: 3
[18:21] Object: 2
----------------------

Yeah, it's async, a state change may work better as a kill switch (can do the delete in the other state).

Out-of-order is chat fairly common, sorry to say.

everytime you change a script as an asset item it takes a little while to process, whatever your tryin to do would be better served with a timer

treat all inventory handling functions like requests to an outside source to do something that you have no control over. (and ll*Say 's or IMS for that matter)

Yes, that worked perfectly, thanks.Ugh!

the out of order chat is probably because someone chose to queue requests in slices and then loop backwards through through slice (for speed/convenience), much like would occur with a touch event in a script. so that if the messages get there within the same slice they're backwards coming out (LIFO or stack order, within a slice)

I suspect the reason is that chats are sent with an application-level retry mechanism rather than being sent in a single tcp connection. Out-of-order chats happen more often when the chat lag is high, which corroborates this, but is far from confirming it, and no; I didn't check the source.

They're also frequently out of order when the time between them is far longer than a slice.

Looping through chats backwards in a timeslice would be a silly design flaw. A list is not enough more efficient than a stack to be a meaningful optimization for this.

Has anyone tested whether chats get received to scripts out-of-order? I wonder if message delivery on the server is in-order, and we simply see them out-of-order on the client end occasionally. This could be tested by queuing up messages heard in a script for a while (and to be sure adding a sequence number to each message), then spitting them all out at once. Test a large number of times and compare carefully where a mix-up of direct messages is seen on the client. Or simply spit out a sequence of numbers from one script to another, report only when they skip or come out of order, and leave it running for a few days.

tested with the following two scripts... the chat stays in order on the server... it's just the viewer receipt that is asynchonous (several out of order sequences on the public chat, zero as heard by the listening script)

string gStrSave;

default{
  state_entry(){
    llListen( 0, "order tester", "", "" );
  }

  listen( integer vIntNull, string vStrTest, key vKeyNull, string vStrMsg ){
    if ("order tester" == vStrTest){
      if ("done" == vStrMsg){
        llOwnerSay( gStrSave );
        gStrSave = "";
      }else{
        gStrSave += "\n" + vStrMsg;
      }
    }
  }

  touch_start( integer vIntNull ){
    llOwnerSay( gStrSave );
    gStrSave = "";
  }
}

default{
  state_entry(){
    llSetObjectName( "order tester" );
  }

  touch_start( integer vIntNull ){
    integer vIntCounter;
    @Loop;
      llWhisper( 0, (string)(++vIntCounter) );
    if (100 > vIntCounter) jump Loop;
    llWhisper( 0, "done" );
  }
}

That's good to know; thanks Void!