Mechanics of the llListen handle?

[Kaeldan Monk]

Hi! I noticed something while I was scripting today that I couldn't quite find an answer to on the wiki, and Google was useless.

I'm writing a script that clears and rebinds a llListen with a different generated channel every time it is touched, and I noticed that the listen handle appears to increment its value every time, even after attempting to clear it and outright set it to FALSE.

Why does this happen? Will this impact the memory usage of the script?

The output looks something like this:

[11:51] Object: Listener: 1, Channel: -696923964
[11:51] Object: Listener: 2, Channel: -696923960
[11:51] Object: Listener: 3, Channel: -696923980
[11:51] Object: Listener: 4, Channel: -696923930
[11:51] Object: Listener: 5, Channel: -696923905
[11:51] Object: Listener: 6, Channel: -696923934
[11:51] Object: Listener: 7, Channel: -696923912
[11:51] Object: Listener: 8, Channel: -696923918
[11:51] Object: Listener: 9, Channel: -696923956
[11:51] Object: Listener: 10, Channel: -696924001

 

Even outright instructing the compiler to set the Listener variable to zero/false is fruitless, so now I'm just wondering what's happening.

Setting up the listen event looks like this:

menu_channel_listener = llListen((menu_channel = set_active_channel_to(owner_key, (integer)(llFrand(100) + 11))), "", NULL_KEY, "");

And I am attempting to clear it like this:

llListenRemove(menu_channel_listener);
            menu_channel_listener = (menu_channel = FALSE);

 

[Rolig Loon]

All you need is the llListenRemove statement.  You are making things unnecessarily complicated by adding that extra line.  Literally,

menu_channel_listener = (menu_channel = FALSE);

means "set the numerical value of menu_channel_listener equal to the value of the expression (menu_channel = FALSE)".  You are getting the result you wanted.  The listen handler is removed. You don't need to take the unnecesary step of setting menu_channel to zero too.  The next time you instantiate menu_listen_handler, it will automatically get a new value, which is exactly what is happening.  The previous value is no longer accessible, since you have removed that handler.  There is probably a very minor loss of memory, but it's insignificant compared to other things that you probably have going on.

To avoid confusing your script, I suggest NOT inlining the definition of menu_channel in your definition of menu_channel_listener.

[Kaeldan Monk]

I see! So I shouldn't worry about the gradually incrementing menu_channel_listener as it instantiates new listeners. That settles my mind on the matter, though I'm still curious as to what function the handle serves when it increments by 1 every time it's instantiated (from 1 to 2, 2 to 3, etc.) and if that eats consumes available memory or not -- which is what prompted my attempt to manually empty both vars.
My concern stems from that I don't expect the script to be reset a lot (it's an in-world dataserver thing -- it will store very little data so I don't expect that to be an issue), so if/when menu_listen_handler is starting to poke at 2 147 483 647 (in the unlikely event that would happen), will the script crash or run out of memory?
Which is why in an ideal world, I'd love for the handle's output in the chat to not be anything higher than the number 1 once instantiated. I couldn't find any documentation to clarify that particular aspect of it, see.

I try to be frugal with memory so I developed a habit of clearing variables whenever I'm done with them, but maybe I don't need to worry so much about that.

Thanks for the explanation and advice though! It's really appreciated!

 

[Rolig Loon]

You're never going to hit that limit, so don't worry.  Watching out for unnecessary memory use is a good habit, but unless you have a really jamb-packed script, it's not something to obsess about. 

[Nova Convair]

The value of a handler is irrelevant, thats why a handler is used.

Details about the implementation is unknown. I don't know about much infos about the compiler and the runtimes. So everything about the background would be speculation.

But lets have a look at the numbers:

The handler is an integer and SL uses signed 32 bit integers. The max positive value is then 2^31 -1 = 2147483647.
If you count up one per second 24/7 then you will need 68 years until you get there.
And what is 2147483647+1? It's -2147483648. (the sign will switch and you are at the max negative number)
An integer can not really overflow. From there you need another 68 years until you will reach zero and then start over with 1 again.
I can imagine that a server restart will start over though so that is just theory and can't be tested.

[Kaeldan Monk]

That's actually really reassuring!

It's easy to forget just how much 2 billion is simply looking at the number. Pretty sure SL isn't even going to be around for 68 more years (I'm hoping it will though!), so that puts my worries to rest!