Just what is the "queue" & other queue Q's

I'm trying to understand better how the email system works for interobject communication. The WIKI and a lot of posts in this forum refer to the email queue. I may be dense about this, but it is not obvious to me what the queue is to and how it works.

I believe it is to a prim which has a UUID since the email is being sent to a particular uuid. Since a multi-prim object takes on the UUID of its base prim, then the queue is still to the base prim. It doesn't appear that the queue is to a script, since there is talk of the email events in multiple scripts in the same prim getting fired by a llGetNextEmail in one of the scripts. Am I correct about this?

Now there is also talk of queues for other things like link messages. I assume that all these queues are different. I doesn't make sense to me to have just one queue for a bunch of different types of data. Am I correct about this?

Next, when llGetNextEmail(address, subject) is executed filtering for a particular subject, how does that work? If the first email in the queue does not contain that subject, does it retrieve nothing? That's what I would expect if this were behaving as a queue. Or, does it have some capacity to skip and hold onto irrelevant messages until it finds the first one that matches criteria?

Finally, what is the point of the "address" in llGetNextEmail? Is this the address of the sender or the receiver? I assume it must be the sender. It wouldn't make sense for it to be the address of the receiver since you would then expect all the emails in the queue to have the same address, related to the prim's uuid.

A "queue" is a list which you add items at the tail, and remove them from the head. Basically, the First item In is the First item Out (FIFO). Think along the lines of the checkout aisle at your supermarket. You get in line, and wait your turn as people who got there ahead of you first are checked out. Same thing applies to the email queue, which instead of shoppers waiting to get checked out, you have email messages waiting to be received.



Correct, emails are sent to objects via the UUID of the prim the script is in.



Yep, that's a different queue, called an "event queue". Imagine, after you get out of the grocery store, you get in your car, and then get in line at the exit of the parking lot to get onto the street. Just as that is a different queue for a different purpose, so are event queues different from email queues. All events that are generated that a script processes via event handlers go into an event queue for each script. That queue is only 64 entries long, so you can't spend too much time in any one event handler, otherwise it could fill up, and you start losing events.

When you receive emails, you have to prompt the email server to send them to you, one at a time, via the email event handler. They appear in the event queue, and the email event handler is called as soon as it can be to process it.



It iterates over all emails pending in the queue to find one that matches. This is an exception to normal queue handling, which allows messages to be received out of the standard FIFO order, but it is still FIFO for all messages which match the filter. Only when no emails in the entire queue match the filter will the llGetNextEmail() request not end up triggering an email() event.



Correct, it is the address of the sender. The receiver field would all be the same address for all emails in the queue. You are filtering the queue based on the sender field, so you can, for example, receive only emails from Object A and leave all the Object B emails in the queue for another script to receive. Do note that the email event still gets called for all scripts in the same prim, regardless of the filter setting or which prim issued the llGetNextEmail call.

Thanks. That helps a lot. So there is the queue for all pending emails for that prim and there is a different queue of emails waiting to be handled by the email event handler once they have been retrieved by llGetNextEmail?

Well, the second queue is not solely for emails, but for all events the script/object can receive. It also includes chat messages (listen() events), touch events, sensor events, collision events, money events, attach events, on_rez events... anything the script has a handler for that occurs ends up in that queue.

On the email server, the queue is simply full of emails to your object. In your script's event queue, there can (and usually is) a potpourri of different items waiting to be processed, including emails sent from the email server's queue down to your object when your script requests llGetNextEmail().

Thanks for your help. That clarified a lot of things for me.

One more question occurred to me. In the email event, there is a parameter called num_left, representing the number of emails left in the email queue. Is that the total number of emails left or just those meeting the criteria specified in llGetNextEmail?

I believe that it is always the total number of emails left in the queue, irrespective of any filters. As such, you wouldn't be able to discern how many emails were left in the queue that matched any particular filter, so you would have to keep asking for the next one that matched based on something like a timer event.