[Solved] Weird hashtable... bug (or not)

[Alain.Mark]

Knowing that we cannot acces a local value type from a seperate thread if it is not returned or stored in a variable, how bout for local hashtables? (i tried this and it worked)

library Box initializer Init
//===========================================================================
 function Capsulate takes nothing returns hashtable
    local hashtable capsule=InitHashtable()
    call SaveInteger(capsule,0,1,1)
    call SaveInteger(capsule,0,2,2)
    call SaveInteger(capsule,0,3,3)
    return capsule
 endfunction

//===========================================================================
 private function Init takes nothing returns nothing
    local hashtable capsule=Capsulate()
    local integer a=LoadInteger(capsule,0,1)
    local integer b=LoadInteger(capsule,0,2)
    local integer c=LoadInteger(capsule,0,3)
    call BJDebugMsg(I2S(a))
    call BJDebugMsg(I2S(b))
    call BJDebugMsg(I2S(c))
 endfunction
 
//===========================================================================
endlibrary

Just wondering if this is a bug or if it even has a use...

 

[Garfield1337]

Why would it be a bug?
In Capsulate function, you return a hashtable you created and you operate with same in Init function. This works for any value.

 

[Alain.Mark]

The only thing i find good about that is that it allows you to acces multiple values using one call... by using a hashtable. But in that case its useless anyway... :U since we already have structs

 

[Adiktuz]

your statement that it allows you to access multiple values in one call is also false... each of your line which calls one function each only loads one value...

also another thing why its useless is that the values you returned are just constants... so just use one hashtable, some variables, variable array, or a struct... and it also just slows you down, as you create the data everytime, then load it, when you can just save it on map init... we never dynamically create constant values...

 

[Dr Super Good]

Firstly that is 1 trigger thread. Calls transfer ownership of the thread to the called function which then transfers back to the calling function when the function returns (all functions return, even if no return is specified. Secondly the hashtable reference is local but the hashtable object is global so it can be used cross thread (if you reference the same hashtable object but that itself requires a global in any case).

Your code will also break if called enough because there is a limit of about 256 hashtables that can be created in a map (and you can not destroy hashtables to free up part of that limit).

The difference between globals and locals...
Locals are stored on the executing thread's stack so are unique to each thread and last as long as the function that created them does.
Globals represent a space in general memory which remains constant and shares its value between all threads.

Although WC3 triggers do have threads (easy to prove with trigger sleep action and locals), only 1 thread at any time will be executed so there is no concern with thread safety and globals (which happens in real life due to caches and Simultanious multi thread processors).

Local handles are just a pointer to a global object. They are not C structs (which can get stored locally and are deleted when the local gets removed). Due to how you interface with handles, it is possible that they are only used within a local scope but you must remember that they still create global objects (which is why WC3 triggers are leak prone).

 

[Alain.Mark]

thanks