How Do Events Go Wrong?

This is more a question to draw on your hard-learned experience. Putting aside the issue of filling the event queue and then having subsequent events get dropped, as well as stack-heap collisions, what sorts of ways do events go wrong? I'm thinking about times when things aren't running optimally - there's high lag for example, or other ways in which the servers are misbehaving.

What sorts of things can I expect, and should I account for if I want to build a robust application? Can events simply disappear? Can they get delivered multiple times? I understand them not arriving in any particular order.

Thanks!

EDIT: I should probably add that I'm mostly interested in inter-script events (llMessageLinked)

Someone please review which "events" are treated as interrupts and which are not....

I wrote a script a while back that relied on sensor events... and assumed that if I triggered a sensor every 20 seconds, the sensor state in the script would be entered.. Nooooo. the default loop ran and ran and ran,, leaving the results of my sensor events unprocessed. When i completed what i thought would be a "tour" of a sim with sensor readings from 10 locations, what I got was a loop that triggered 10 sensors, but did not process any of them until the movement had completed..and then i got 10 sensor events triggered in the final location?????. Having written menu listeners, it seems that the timer event functions as an "interrupt", effectively branching out of whatever is going on, and then "returning"...
I re-wrote my script and included 30 second "sleeps" between triggering the sensor and moving to the next location,, but even the "sleep" function seems to prevent the sensor event from processing... what kind of function prioritization is that?

So there are all kinds of things referred to as "events" but there sure seems to be widely disparate behavior in the triggering and handling of the processing....

Finally, Love, I've just finished reading that llMessageLinked events are reported to be unreliable.. and the suggested workaround was to make sure that they were delivered... Of course the same author who suggested there were "unknown" reasons why they were not delivered suggests a workaround that requires a "reply" message (using the same unreliable mechanism) to confirm delivery...

Dz, I haven't played with sensors much, so I could be off base. However, a script can only have one thread of execution at a time. If you want to receive an event, you have to give up your thread (that is, fall out of whatever event handler you are currently in). So I think the basic technique is move your object, trigger the sensor, exit. When the sensor event arrives, record your data, then move to the next location, trigger your sensor, exit, etc, etc. Timer events are no different. You can only receive them when you don't have a running thread.

ther was (may still be) a problem with large numbers of link messages having intemittant spot failures, like when broadcasting to a large number of children with LINK_SET and LINK_ALL_OTHERS, especially with frequency.... I'd assume slow servers would be more prone. it was only random single failures, dunno if it's still a problem.

So it's reliable then, generally speaking? What form did the failures take? Lost messages?

It's actually pretty easy to run into the maximum event queue size of 64 with link messages. Scripts used to distribute script delay for IMs and e-mails to many recipients can run into it quite easily, and thus you want to try to direct messages to specific prims so not all scripts have to queue them up. I've personally never seen link messages arrive out of order. From what I can tell they either arrive in order or some don't arrive due to being discarded when the queue is full.

As I understand it NO events are treated as interrupts.

Events are pushed onto a que, once the event you are in has completed, the event at the head of the que will be proccesed.

So adding a sleep to an event is one of the worst things you can do, it simply delays the completion of the event you are in and aloows the event que to build up and possibly overflow.

I think this is the case, but if I'm wrong some one will no doubt be along to correct me shortly

Very right Beverly. Each script is single-threaded. No event handler will execute while another is running.