Funny Bug

[GManB]

Even though the lsl execution environment does it's best to abstract the fact that, when we have code communication among objects, which is a lot, we are building Distributed Systems (in the fullest sense) we are still building Distributed Systems. Hence all the concurrency issues that arise in such systems need to be considered.

 

I have a system of one object (the main board of a game, MB) communicating with up to 30 player HUDs. Communications are pretty simple but concurrency issues still occur.

I had the system about ready for a beta test with some friends so went through the two files and did a global replace to comment out all the llOwnerSay() calls. (I wanted local clear of degug messages so friends and I could chat).

System totally deadlocked when the first HUD was attached (lucky I caught this before friends came over lol).

Files are about 500 or so lines. But I had no idea where the bug might be. So I undid 1/2 the global replace in one file and lucked out in that the system worked properly.. So took out 1/4 of the llOwnerSay calls... and proceeded until I found the bug. I happened to have an llRegionSayTo() and llListen() in a function, which was in the initialization phase of the system, with a few calls to llOwnerSay() between them. Taking out the llOwnerSay() calls meant the message got to the receiver and the receiver responded before the llListen() was called. Swapping the order of llRegionSayTo() and llListen() fixed the issue... something I SHOULD have caught when I was coding... sighs..

I did get all the llOwnerSay() calls out and system working as friends were arriving!

G

[Rolig Loon]

Chat lag is real.  People in crowded clubs and music venues mutter about it all the time.  There's not supposed to be any perceptible delay in sending/receiving messages with LSL, but it does happen when the servers are under stress.  

[Wulfie Reanimator]

28 minutes ago, GManB said:

Taking out the llOwnerSay() calls meant the message got to the receiver and the receiver responded before the llListen() was called. Swapping the order of llRegionSayTo() and llListen() fixed the issue... something I SHOULD have caught when I was coding... sighs..

It's a pretty funny bug, but I don't think it has anything to do with "concurrency."

No matter what kind of system you're working with, you should never expect to be able to expect a response before you've registered a listener. Neither should you expect there to be a long enough delay before the response, that you should have enough time to register the listener after-the-fact.

Edited September 23, 2020 by Wulfie Reanimator

[Ardy Lay]

Time in Second Life is both non-linear and granular.  We have no assurance that there will be any concurrency in script execution at all since scripts in a simulator appear to all be run by a single scheduler in "passes" or some such.  What is interesting, and illustrated by your example, is that a "pass" can include multiple instructions up until an event needs to be serviced to continue.  I some respects it's like working with programable logic controllers that use relay logic and scan intervals as opposed to real relays and wires.

As Wulfie advises, you should always ensure the catcher is ready prior to pitching as there is no assurance the catcher will get any execution time in which to get ready after you throw your pitch.  It is also quite possible the catcher will be able to catch the ball and toss the ball back to the pitcher before the pitcher gets any additional execution time after throwing the pitch!  So hold that glove up before you throw the ball!

[Lucia Nightfire]

Chat is such an archaic/slow method of doing things in SL.

We need methods that can achieve direct/remote memory/object manipulation as if this was a game environment.

It would be great if Mod Keys could be implemented to tackle this.

[Kyrah Abattoir]

1 hour ago, Lucia Nightfire said:

Chat is such an archaic/slow method of doing things in SL.

We need methods that can achieve direct/remote memory/object manipulation as if this was a game environment.

It would be great if Mod Keys could be implemented to tackle this.

That or scriptable interfaces/message systems.

[Rachel1206]

1 hour ago, Kyrah Abattoir said:

That or scriptable interfaces/message systems.

@Kyrah Abattoir I am sure @Lucia Nightfire means scriptable interface, I could imagine something like link_message direct among objects only independent of the existing chat system.

[Kyrah Abattoir]

1 hour ago, Rachel1206 said:

@Kyrah Abattoir I am sure @Lucia Nightfire means scriptable interface, I could imagine something like link_message direct among objects only independent of the existing chat system.

No i know which jira she is refering to.

[Nova Convair]

I don't see a bug here, except in the script.

LSL never guanrantees that something happens in a specific order or timeframe - so you need to script in a way that timing and order doesn't matter.
You always need to get the listen to work before you start any type of communication.
If you rez something the rezzed object is ready when it sent a message that tells it is ready.
You can get away by adding intentional or unintentional delays but that fragile construct will crash on heavy lag or the absense of lag or whenever LL changes something or if you change something.

Everybody had their "aha" moments in scripting but you get used to not make expectatione but get certainty.

[Wulfie Reanimator]

5 minutes ago, Nova Convair said:

If you rez something the rezzed object is ready when it sent a message that tells it is ready.

And on the flipside... just because you've literally just received an event from an object doesn't mean the object/UUID is valid anymore.

Classic example: Detach, llSetDamage, llDie on collision, etc.

Edited September 24, 2020 by Wulfie Reanimator

[GManB]

13 hours ago, Nova Convair said:

I don't see a bug here, except in the script.

Agree. Calling llRegionSayTo() before llListen() was a coding error. The coding error introduced an 'artificial' race condition

Thinking a bit deeper, we should be able to assume that the script calling llListen() will actually have all the mechanism in place and be ready to listen before llListen() returns. If this is true then calling llListen() before, e.g., llRegionSayTo() is correct and will never result in a race condition. I can't imagine the opposite being the case.

 

G

[Rolig Loon]

Maybe not in the context of your sending script alone, but there could certainly be a race condition if the sending script sends a llRegionSay message before the receiving script is ready to listen.  Any number of conditions in the region might keep the receiving script from waking up in time to hear.  Sometimes it may be necessary to ping several times until you get a verified handshake, for example.