Rework function delays in slua
under review
Iain Maltz
Rather than having in built "freezes" in certain functions like object rez / ll email etc, which are trivially circumventable by "LINK_MESSAGE"ing another script in the same prim and having that other script swallow the delay (providing a 'burstable' limit on these calls) these could be better handled in slua by reworking how these delays are implemented - perhaps on a per prim or per script setting where these calls can be made at "no cost" up to some specific rate after which they stall or fail (for example the way HTTP requests can be performed - there is no function delay here but there is still an overall limit on HTTP requests)
The work around of having often multiple 'worker' scripts that just listen for a link message then execute the call to llEmail / etc has always been a bodge, but also rather necessary one if you don't want your main server script to become unresponsive regularly, which is quite important for a simultaneous multi user server style script (e.g. providing a region wide service to all players, the main script here can not be stalled without noticable impact to the players and yet some of these functions with delays in are needed for operation).
Made a longer post here https://community.secondlife.com/forums/topic/530018-of-functions-with-delays/
Since so much is changing in the lua implemented stuff we could use this opportunity to redefine or rework how these function delays work, /only/ for pure lua scripts compiled using the new lua mode, while legacy LSL to lua / LSL mono / LSL classic scripts can maintain their previous behaviour regarding delays.
This would be great to avoid what is essentially a "gotcha" that new scripters sort of 'need to know' how to work around to have a performant system that needs to use these delayed calls, as well as avoiding the wasted overhead of multiple worker scripts with their overheads and the time wasted in link messaging (especially since all the worker scripts receive all link messages even though only one of them will take up the work)
Would just be a great and rare opportunity to revisit a rather archaic piece of the scripting languages implementation that just doesn't really work as advertised anyway once you know of the bypass by offloading to worker scripts, not often breaking changes can be brought in to a new language checkpoint.
If this isn't clear enough please let me know and I'll give some better examples or something but I assume this fairly trick is widely known.
Log In
H
Harold Linden
marked this post as
under review
H
Harold Linden
Thanks for sending this in!
This seems more related to "scripting features" in general to me, since it's about a design problem in the scripting system in general, and it'd be nice to solve for LSL as well.
I broadly agree with this. I have a lot of thoughts about how throttling / forced sleeps / whatever currently work in SL and none of them are good.
Fundamentally, I think that a lot of the existing limit implementations in LSL either fail to meet their goals (preventing non-trivial abuse of resources), impose limits that are well below what reasonable scripts might need to do in practice, or are opaque as to when they are applied or will expire.
Forced sleeps aren't effective for the reasons you've stated. They're trivially circumvented by using multiple scripts, forcing you to abuse resources to circumvent unreasonable limitations intended to prevent resource abuse. The perverse incentives the current solution creates are arguably worse than the problem it intends to solve.
With
llTextBox
in particular, there's no obvious indication to the script that the call even failed, or that the request would violate the throttle limit.In short:
* A lot of existing limits are not reasonable for common usecases, so people work around them
* Script-specific limits are bad, it's easy to create new scripts and bridge them with
link_message
.* Linkset-specific limits are better _if_ they're reasonable, they're harder to circumvent
* Fixed, forced sleeps per-invocation are bad, it's much nicer to allow bursts before invoking your limiting behavior
* Not using fixed, forced sleeps gives you the option of using separate "bins" for various kinds of limits.
* It's better to have some indication of what the limit is, and give an indication that an error happened if possible. Shouting on the script error channel is not sufficient.
* If people can receive an error that says they can try an operation again in
n
seconds, they can make their own decision about whether to sleep or just do something else.Given that, I think there needs to be a broader conversation about how to implement limitations in a way that actually works for both scripters and LL.
Nexii Malthus
Per my later reply in the thread.
The scripts in SL have different penalties:
- Energy
- Sleep
- Throttles
Each was part of a certain era and based on advancements and capabilities of the platform.
Throttles are the latest addition to that and are much nicer on scripts (and scripters) being able to be responsive without exploding the amount of scripts needed.
I think that both Energy and Sleep are unnecessary for modern SL scripting and should not be part of the platform going forward.
WolfGang Senizen
Nexii Malthus Especially if the throttles are well documented and failures catch-able with pcall
SuzannaLinn Resident
Another use case:
In my scripting classes, I have an object that gives a folder with class materials on touch.
The object has a master script with the touch event and 9 giver scripts calling ll.GiveInventoryList() that are linked messaged in a round-robin fashion.
Since ll.GiveInventoryList() sleeps for 3 seconds, using a single script would mean some students would have to wait more than a minute to receive the contents.