Jump to content
Linden Lab

Parent/Child object Script Communications

Recommended Posts

Posted (edited)
Quote

As part of our ongoing efforts to improve script performance, we recently made changes to how scripts are scheduled and events are delivered. [...] We have now made further improvements that should prevent most of those problems, but even with those fixes there will be some changes in the timing and order of how scripts are run.

Can you go into any specific details about those changes? (Talk techy to me, LL.)

Or at least, what can we as scripters expect that is different from before, or is this just a performance increase?

Why did content break, or was it only because of those already existing race-conditions?

Edited by Wulfie Reanimator

Share this post


Link to post
Share on other sites
20 minutes ago, Wulfie Reanimator said:

Can you go into any specific details about those changes? (Talk techy to me, LL.)

Or at least, what can we as scripters expect that is different from before, or is this just a performance increase?

Why did content break, or was it only because of those already existing race-conditions?

I'm not going to go into details about what changed beyond saying that some events (notably chat listens) were being collected and distributed once every script execution for every script. They are now queued immediately to the subscribed script(s) removing some work from the scheduler. 

The window between the object_rez event and on_rez() has become more variable and the delivery of chat messages to a channel has become faster. So, scripters that already use a handshake as recommended in the blog post will not notice any difference and their scripts will continue to work. However if the rezzers are relying on a timeout to determine when their rezzed object is ready, those scripts may break. 

on_rez() in multiple scripts should all occur within a server frame or two of each other (depending on the script load of the server), however the order in which they occur remains arbitrary. 

  • Thanks 7

Share this post


Link to post
Share on other sites

A nice solution would be to have the API pass a string, instead of just an integer, when rezzing something. Then all the info the rezzed object needs to start could be packed into a string, using the CSV or JSON functions. No race conditions and no handshaking.

Share this post


Link to post
Share on other sites

I've seen quite some failures over time and never trusted undocumented timings or that things happen in an expected order.
So I'm not affected here.
Having a string as rez parameterr would simplify rezzing quite a bit though.

Share this post


Link to post
Share on other sites
10 hours ago, animats said:

A nice solution would be to have the API pass a string, instead of just an integer, when rezzing something. Then all the info the rezzed object needs to start could be packed into a string, using the CSV or JSON functions. No race conditions and no handshaking.

agree that being able to pass a string would be useful for the one-way case

altho Rider's case is about the two-way, the rezzer validating the presence of the rezzee before doing stuff (like Inventory Drop) on the rezzee

in the one way case when we need a bit more than an integer's worth of data, then currently a way is for rezzee to read the rezzer's object description field

Share this post


Link to post
Share on other sites
45 minutes ago, Mollymews said:

... currently a way is for rezzee to read the rezzer's object description field

... tempting scripters to invent their very own race conditions

Share this post


Link to post
Share on other sites
2 hours ago, Qie Niangao said:

... tempting scripters to invent their very own race conditions

can be yes, depending on how is done

the main issue is when a rezzer is rezzing objects on a fast timer, where is possible for a unique message intended for rez_object_1 to be replaced by a unique message for rez_object_2 before rez_object_1 retrieves its own message. We can know when this happens by using a unique identifier for each rez_object instance passed as the rez parameter. Example:

// rezzer

rez_id++;

string msg = (string)rez_id + ":Some message for this object";

llSetObjectDesc(msg);
llRezObject(... rez_id);


// rezzee

on_rez(integer param)
{
   key parent = llList2Key(llGetObjectDetails(llGetKey(), [OBJECT_REZZER_KEY]), 0);
   list desc = llParseString2List(llList2String(llGetObjectDetails(parent, [OBJECT_DESC]), 0), [":"], []);
   if (param == (integer)llList2String(desc, 0))
   {
      string msg_for_me = llList2String(desc, 1);
   }
   else
   {  // is not for me
      ... do fallback position: open a channel to rezzer ...
   }
}

 

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)

@animats & @Nova Convair

"Let's pass a string instead" is kind of out of the scope for this topic/update, though.

Besides, it's an impossible request in its current form because changing or adding a string to on_rez would (almost, if adding) definitely be a breaking change.

Edited by Wulfie Reanimator
  • Like 1

Share this post


Link to post
Share on other sites
12 hours ago, Wulfie Reanimator said:

Besides, it's an impossible request in its current form because changing or adding a string to on_rez would (almost, if adding) definitely be a breaking change.

Changing parameters on an already published API is not really a possibility.  It would absolutely be a breaking change.

Share this post


Link to post
Share on other sites
16 minutes ago, Rider Linden said:

Changing parameters on an already published API is not really a possibility.  It would absolutely be a breaking change.

Right. SL doesn't have the Microsoft tradition of adding a new API endpoint with a suffix, such as GetFileAttribute and GetFileAttributeEx, for a breaking change that has to be backwards compatible. That's one way out of that problem. It's not worth the hassle for this, though.

Share this post


Link to post
Share on other sites
9 hours ago, Rider Linden said:

Changing parameters on an already published API is not really a possibility.  It would absolutely be a breaking change.

 

9 hours ago, animats said:

Right. SL doesn't have the Microsoft tradition of adding a new API endpoint with a suffix, such as GetFileAttribute and GetFileAttributeEx, for a breaking change that has to be backwards compatible. That's one way out of that problem. It's not worth the hassle for this, though.

Not really follow this, but as far as LSL and rezzing is concerned, adding another parameter isn't rocket science.

Rezzer key is the most recent example of data added that never existed before.

It had to be added to prims as a detail, it had to be added to the rez queue to be passed on.

To facilitate a "start_string" param, you would need a new rez function that accepts the input, a change in the rez queue handler to accept the new data to pass on.

In the rezzed object, you would need a function similar to llGetStartParameter(), say llGetStartString().

Is it worth it making this kind of change? Most likely not as, depending on data size, current methods like checking rezzer desc, using chat or using KVP are good enough.

Share this post


Link to post
Share on other sites

Asynchronous tasks. You have to write them both assuming that you know nothing about the state of the other task that it hasn't explicitly told you.

I'd lay odds that just about every beginning coder has written themselves at least one race condition before these rules got properly wired into their heads and got burned by it.

We've a lot of gifted and creative folks in SL who are not professional coders, who did not come to LSL with the mental bruises to teach them why "this is always the way you do it, even if it looks like a simpler way will work." There's bound to be a lot of this out there on the grid, and it is the nature of race conditions that they are usually exposed as performance improves.

That these LSL coders are in this position of having their scripts break under a performance improvement is not LL's fault, but nor would it be fair to say that it is entirely the coders fault either. This is their encounter with that painful lesson that almost all more experienced coders have had in their own history - it is part of the "experience" that causes a 'less experienced coder to become a more experienced one.

It's like triggering an animation when somebody sits on the object "knowing" that animation perms are automatically granted by a seated avatar instead of requesting them and waiting for a run-time-permissions event. Exactly the same race condition.

 

Ultimately, since the performance improvements which expose these race conditions are now critical, I don't see that LL will have any choice but to publicize this as widely as possible for a short time and then bite the bullet and roll the update, letting the chips fall where they may for scripts that subsequently reveal themselves to have been mis-coded. Sadly, this means that where an object's scripter is no longer around or no longer supporting the object, if it contains this kind of error in its scripts that object will likely be junk. We've been there before. It wasn't pretty then and it won't be pretty now, but for all the inactive scripters whose legacy objects fall into obsolescence there will be others who are active and will create objects to fill the void, coding them to avoid this pitfall.

  • Like 1

Share this post


Link to post
Share on other sites

Is there a chance that the update here is making it so that some scripts don't execute at all, or are delayed indefinitely?  I've noticed a bunch of RLV things breaking on Dolly Dreams, which gets fixed with a region restart.  But when things stop working, it's like script roulette.  To be clear, these are scripts without a race condition, but simple things like a menu not popping up when requested by a link message spawned from a touch event, as if the script were not executing at all.  Are you sure this is working as intended, and every script is subscribed to the appropriate listens?

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...