Event Queue

[Wandering Soulstar]

Hi All,

I have a question in regards to the queuing of event.  Now the Wiki states:

Quote

Events do not interrupt each other, but instead are queued FIFO, though the state_entry event can jump the queue. If more that 64 events are waiting, new events are discarded until free slots become available

So seem very straight forward, my question though is does this mean upto 64 calls to the same event? What I mean is:

Have a script that is going to send out a call to other prims on a chat channel: 'Hey .. who is there?' in effect. Each prim that has a listener script will respond, using llRegionSayTo with some specific data. There definitely will not be anywhere near 64 answering, more in the range 20-30. The order I receive the responses is immaterial, I just want to be certain I receive them all. My planned code in general was:

list gCallers = [];
list gMessages = [];
integer sHandler;

default
{
    state_entry()
    {
        gCallers = [];
        gMessages = [];

        sHandler = llListen(CALL_CH, EMPTY_STR, NULL_KEY, EMPTY_STR);
        llSay(CALL_CH, "Please Check In");
        llSetTimerEvent(5.0);
    }

    listen(integer channel, string name, key id, string message)
    {
        if (channel == CALL_CH)
        {
            //store and reset timer ...
            gCallers = gCallers + [id];
            gMessages = gMessages + [message];
            llSetTimerEvent(5.0);
        }     
    }

    timer()
    {
        llSetTimerEvent(0.0);
        state do_work;
    }

}

 

Anything I'm missing here? .. seems like it should work ... have not tried yet .. not able to get in-world ?

Thanks in Advance!

Wanda

[Wulfie Reanimator]

All events go into the same queue, so the 64 limit is a total one.

Now, even if you had over 64 responses, in practice your script will likely process some of those events before the event queue is exceeded due to the lag time from the responding scripts. (Not all of them will react exactly at the same time, even if they receive the message at the same time.)

That's kind of an aside though, since the lag is unpredictable and relying on unpredictable things is never wise. Especially with the more responses you might be expecting.

I don't have any experience with dealing with maxed event queues so I don't really have many suggestions. 

[Love Zhaoying]

No, 64 total events, could be different. 

[Qie Niangao]

33 minutes ago, Wulfie Reanimator said:

(Not all of them will react exactly at the same time, even if they receive the message at the same time.)

Right, and the responders could be scripted to add some dispersion to response arrival time by introducing a brief, random wait.

Another approach is for the senders to await an acknowledgement from the intended recipient (that llRegionSayTo() in this case) and if that interval times out, repeat the response -- perhaps again after a random "back off" interval.

In this case, though, it all seems like overkill unless there are conditions under which multiple initial "please check in" message could be received nearly simultaneously.

[Rolig Loon]

56 minutes ago, Qie Niangao said:

Right, and the responders could be scripted to add some dispersion to response arrival time by introducing a brief, random wait.

That's my usual approach if I know that I will have many scripted objects all trying to do the same thing (send a message, rez and object, reset their scripts,...) at once.  It not only helps avoid overloading the event queue, but also reduces region lag.

[Nova Convair]

Imagine this scene:

Object A has a script that sends out a message 1000 times - as fast as possible - and a time measuring.
It takes about 1-2 seconds to send 1000 messages.

Object B has a script that receives this messages and counts them - and a time measuring - triggered by a start and a stop message included in the 1st and last message of Object A.
A script can receive about 12-15 messages per second as it turns out.

 

What happens?

Object A runs for one second then it has fired out 1000 messages

Object B runs for about 70 seconds and reports that it has received 1000 messages

 

Conclusion

The event queue is 64 entries, but the sim obviously runs a message buffer in a way that it does not overrun the event queue of a script. The size of the buffer is limited. If i send longer messages or 5000 instead of 1000 messages then Object B reports less received messages than were sent by object A.

So the chance of missing a message are almost zero - except the sim is full of communicating scripts.

 

[Wandering Soulstar]

Thanks to all for the responses! Definitely will never be getting anywhere near the 1000 message range ?