The problem with a fixed maximum guranteed memory per script is that it
doesnt' add a limit for more than one script, so several scripts could
be using the minimum guarantted and not veing capped.

My idea is to haev a fixed per meter and per avatar maximum guaranteed
memory, anything baove guaranteed. Scripts using more than that are out
of the safe limits.

We Need somthing like llGetSimFullMemory, llGetSimFreeMemoy,
llGetParcelFullMemory, llGetParcelFreeMemory, llGetOwnerFullMemory and
llGetOwnerFreeMemory. And i like the idea of an event to be triggered
before the script either looses some of it's avaiable memory or is about
to be shut down if it doesn't start using N less bytes of memory,
somthing like:

less_memory(float bytes_to_loose)


The sun wauts tgat evebt ti ebd fir a secibd ir si abd uf ut diesb't ebd
vefire tgatm ir uf after that the script still hasn't lost enough bytes
in it's ram footprint the sim will shutdown the script (perhaps save the
script state of not running scripts on disk and not on ram?)




Melinda Green escreveu:
> Perhaps a hybrid design might make for a reasonable compromise between
> predictability and flexibility. Something like hard lower memory
> limits that scripters can count on always being available, plus the
> ability to request and receive provisional amounts beyond that which
> might get yanked back at any time. If you go beyond the safe limits,
> you take your chances. There may even be more gentle ways to deal with
> these worst-case situations, for example by creating an LSL event that
> informs scripts when they are about to lose some or all of the
> provisional memory that they are using, giving them a chance to get
> back under a safe limit and avoid getting shut down.
>
> I suspect that Qie Niangao is right that some non-trivial optimization
> logic is called for here. To me the situation feels like operating
> system design. In many ways the simulators *are* simple operating
> systems. Perhaps talking with some Linux kernel developers might
> identify some libraries that can be used to manage script resource
> allocations. I don't know because OS design is not my field but I
> suspect that there are no simple solutions to this problem and that it
> would not be smart to try to reinvent its solutions.
>
> -Melinda
>
> Ambrosia wrote:
>> But in your example, the script uses the max of the sim til the avatar
>> comes in. The script will crash, as the avatar takes his own share of
>> memory, and the script suddenly has less than it actually uses (not
>> what it -could- use but doesn't).
>>
>> Scripts -will- be able to check available memory, that much has been
>> stated, and they reserve additional memory they need with another
>> function, but that available memory should not depend on factors of
>> what's going on outside the parcel or on other avatars aside of the
>> own.
>>
>> Quite frankly, the only thing that makes sense for scripters and
>> content creators are hard numbers they can work with. Fixed memory
>> amounts. Every 512sqm parcel should always (normally) support X mb
>> max. Every avatar should normally support Y mb max. A solid api to
>> build scripts upon. Available memory depends on the scripts already
>> attached to the -same- avatar or on the -same- parcel, but a parcel's
>> or avatar's memory should -not- be dependant in any way on external
>> factors like other avatars or parcels. It makes things unreliable,
>> unpredictable.
>>
>> On Thu, Dec 17, 2009 at 16:10, Tigro Spottystripes
>> <tigrospottystri...@gmail.com> wrote:
>>  
>>> There should be a way for scripts to check how much memory is avaiable
>>> int he pool for the sim, and for the parcel, and also how much memory
>>> the script will be limited to under a worse case scenario,
>>>     
>> _______________________________________________
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/SLDev
>> Please read the policies before posting to keep unmoderated posting
>> privileges
>>
>>   
>

_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/SLDev
Please read the policies before posting to keep unmoderated posting privileges

Reply via email to