After the weekly server update, rolling a Release Candidate version to the main server channel, scripters started seeing reports of missed messages between scripted objects and items those scripts rez. (A hypothetical example might be a custom-scripted chair that rezzes a table and then tells the table to color itself to match the current chair color.)
After some sleuthing they figured out that the rezzing scripts were trying to send messages before the rezzed objects' scripts were ready to receive them. But this problem hadn't happened before.
This was NOT because the recipients were slower getting ready, but rather because the senders were unusually quick. That was because they get notified when their rezzed item is indeed rezzed -- which used to coincide with it being ready to receive messages. Not anymore.
In fact, that sequence was never guaranteed. It just worked that way. For years. In a lot of scripts.
Working to speed up script processing, the Lab had streamlined notification of successful rezzing - a good thing, except some user scripts were unintentionally relying on that being no faster than it always had been.
To restore functionality to those scripts, Lindens rolled back the entire grid to the old server software while they work on a change to delay that specific notification until the recipient scripts are ready to get messages. That will make predictable the sequence of these events, removing risk of this particular race condition in user scripts.
Streamlining script processing could have other unexpected effects, as might other speed improvements. Sim crossings are particularly sensitive to timing, for example, so they could be affected -- for better or worse -- by subtle changes in the speed of script processing or by future timing changes as Second Life sims move to the cloud.
Such race conditions are notoriously hard to diagnose and fix. Even more so when the "race" is in user scripts supported by a changing platform.
Reporter Qie Niangao