Are linked messages being queued ?

Just a quick simple question really ... all is in the subject

If you need more information... here is what I'm trying to do.

I have a core script that needs to send e-mails, but sending an e-mail delays script for 20 seconds, i can't afford that in my core script, it has stuff to do
So i thought, i could make a second script, that would just be there to send and receive e-mails, exchanging informations with the core script via linked messages.

So when my core script wants to send an e-mail, it sends a linked message to the other script, and that other script send the e-mail itself.

But what happens if the core script sends more than one linked message within 20 secs ? (that would not be constant, it just "could" happen) Would the second script store the linked message? and after the 20 secs delay it would read the pending linked message and eventually send an other e-mail ?

they are queued up to 64 link messages, after which they are dropped... I don't remember if that is a per script, per prim, or per object queue though, so be cautious.

I think *ALL* messages (or events, as I like to think of them) are queued..

I also think it's per-script, though Babbage may (or may not) mess with that with the upcoming limits stuff - I haven't heard either way on that one but if they see excessive queuing as a problem, they'll probably at least think about it.

Thanks for your quick answers

I should probably hide this then...

 /*//-- Link Message Storage archive, stores in strings, referenced by key --//*/ 
integer gIntCnt;
integer gLnkNum;

integer gIntRqs;
key gKeyRqs;

default{
  state_entry(){
    gLnkNum = llGetLinkNumber();
  }

  link_message( integer vIntRqs, integer vIntAct, string vStrDta, key vKeyDta ){
    if (gLnkNum == vIntRqs){ //-- this is our data
      if (gIntRqs && gKeyRqs == vKeyDta){ //-- do we need to do something with this record?
        if (gIntRqs == 1){ //-- send requested dat to root and re-store it
          llMessageLinked( 1, 1, vStrDta, vKeyDta );
          llMessageLinked( gLnkNum , vIntAct, vStrDta, vKeyDta );
        }
        if (gIntRqs == -1){ //-- delete this data
          //-- we could report successful deletion...
        }
      }else{ //-- re-store the data
        llMessageLinked( gLnkNum , vIntAct, vStrDta, vKeyDta );
      }
    }else if (1 == gIntRqs){ //-- this is a root request
      if (vIntAct){ //-- not a storage request
        gIntRqs = vIntAct;
        gKeyRqs = vKeyDta;
      }else{ //-- storage request
        if (gIntCnt < 60){ //-- do we have enough room?
          ++gIntCnt;
          llMessageLinked( gLnkNum, 0, vStrDta, vKeyDta ); //-- store it
          vIntAct = 1
        }
        llMessageLinked( vIntRqs, 0 | vIntAct, vStrDta, vKeyDta ); //- report stored or full
      }
    }
  }
}

By messages, which I still think of as events, I meant ANY callback from the sim. Timers, link messages, listens, etc.. Anything that wants to happen but gets queued up because the script is busy doing something else.

If LL finds that they're spending 25%, on-average, of the sim script time queuing events, they're probably gonna take another look at that whole mechanism. Or, rather, once it starts causing stuff to explode, they'll schedule a look at it for the following year.

I know, I was just being silly... and it seemed an apt enough demonstration of the kind of queuing that's likely to be looked at

timers, not so much, since they only queue once, without adding significant script-external overhead like link message, http, dataserver, listen, or e-mail do. incidentally those are communications protocols with recieving events... some of the other receptive events would probably be looked at, especialy one that can collect large amounts of data (that often goes mostly unused) like touch, sensor, collision, and a few others

There is only one queue per script, 64 events deep, and holds all events, including link messages. If the script is busy, any event that the script is set to handle in its current state will be queued. So, if the only event in your script's current state (most likely the default state) is link_message, then it will queue up to 64 of them before they start getting discarded. That is ALL link messages which target that prim directly, or as part of a group (LINK_SET, LINK_ALL_OTHERS, etc), so if you use link messages for other things, they can also get queued for that script as well.

64 deep for ALL events? I did not know that.... would that include events for which there is no handler or are those silently discarded? there's some interesting implications there.....

It appears events with no handler in the current state are silently discarded, and most likely not generated to begin with (listens are dropped on state changes, and an llListen in a state without a listen() event may set up a listen, but listen events never get queued; link_messages sent to all prims are not queued for scripts without link_message events).