On Wed, Jul 8, 2009 at 8:37 PM, Argent Stonecutter<[email protected]> wrote: > The correct solution (don't rez the object, leave it > in inventory) seems too obvious.
This sounds like a potential race condition, since rez requests are not instant and load-in takes time. Assume two people want to rez objects on a parcel with limited space. Both attempt to rez a high prim object from inventory at the same time (or within milliseconds). 1. The sim does a precheck for space availability for #1, finds enough room, starts the load-in 2. Asset system is being slow again 3. The sim does a precheck for space availability for #2, finds enough room, starts the load-in 4. Object #`1 rezzes 5. Object # 2 attempts to rez but fails due to insufficient capacity, same old problem occurs.. ====== The alternate solution to this is: 1. The sim does a precheck for space availability for #1, finds enough room, starts the load-in 2. Asset system is being slow again 3. The sim does a precheck for space availability for #2, finds that another load-in is pending and not completed yet, and so aborts the rez attempt. 4. Object #`1 rezzes Though this may lead to a possible "denial-of-rez" exploit by continously streaming rez requests of objects that quickly delete themselves, to keep the "rez queue" busy and prevent other people from rezzing objects since the sim always says "sorry, someone else is rezzing right now, cannot complete request", even in a fairly empty parcel or sim. ====== It appears that the real problem is, if a parcel is overflowed, the sim tries to bring the number of objects back down to within limits by any means necessary, and it apparently is not aware of the order in which objects are added into a parcel so instead it randomly returns objects. Perhaps what is really needed is the capacity for a load-in of prims to be backed-out via a form of disk-partition journaling / transaction-tracking. If the parcel is found to be full when the load-in is asynchronously completed by the asset system, it can be safely backed out from the journal data. But next you run into problems of deciding how big this journal should be, since it adds more processing burden to the sim, to track the rezzing of everything in the sim in order to permit rez back-out. If a sim allows 15,000 objects then the journal should probably be a few multiples as large, since it is apparently theoretically possible to attempt to rez a 15,000 prim coalesced object in an empty sim. If two people try this at the same time the journal would need room to buffer the insane amount of rez overflow, and not wreck the rest of the existing sim.. so a 45,000 prim journal should be unreasonably large enough. :-) _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges
