Survey for prioritizing future projects

Jim Purbrick (Babbage) babbage at lindenlab.com
Thu Jun 26 09:56:54 PDT 2008


There are 2 main drivers for the script resource limits project:

1) Remove the ability to degrade the performance of a sim by creating
many scripts, either intensionally or due to the tradgedy of the
commons. As soon as simulators start swapping their performance tanks
and perceived lag shoots up, we need to be able to limit the memory used
in simulators by scripts, physics, prims and everything else.

2) The desire to base script limits on available resources rather than
arbitrary per script limits. Once we have parcel and agent pools that
limit the total amount of memory used by scripts in the pool, we can
remove limits on individual scripts. No more 16K or 64K memory limits
for scripts. I personally am really looking forward to that change.

Script resource limits would also be rolled out in a number of phases if
we developed it. The first client of script resource limits is likely to
be HTTP In. Instead of assigning an arbitrary limit on the number of
public URLs a script can request we can use a first version of the
script resource limits framework so the URLs will be drawn from a pool.
If it makes sense for a single script to request many URLs, that's what
you'll be able to do.

The next client would likely be memory, as the 16/64K memory limit is
incredibly painful.

Drawing CPU cycles from pools would be a later client and might not be
done at all as CPU cycles are reasonably limited at the moment anyway.

I'll try to get a more complete design up on the public wiki as soon as
I can so you can get a fuller picture of the proposal.

Cheers,

Jim

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
Url : http://lists.secondlife.com/pipermail/secondlifescripters/attachments/20080626/242aa0a3/signature.pgp


More information about the secondlifescripters mailing list