[sldev] Unexpected objects return in group land

Dale Mahalko dmahalko at gmail.com
Thu Jul 9 02:23:59 PDT 2009


On Wed, Jul 8, 2009 at 8:37 PM, Argent
Stonecutter<secret.argent at gmail.com> 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. :-)


More information about the SLDev mailing list