TruerWords Logo

Search TruerWords

Sign Up  Log On

Thread-based Global Variables in UserTalk

Thread-based Global Variables in UserTalk

Most UserTalk developers probably don't realize that the language supports thread-based global variables. They probably woudn't even know what I'm talking about, in fact. For a long time, this feature was hidden in the language, but one of the recent versions (8?) included a new script: thread.getGlobalAddress().

Thread globals are variables that are available to all scripts called in a given execution thread (like a single web server request, for example), so long as the script that created the global is still on the stack. The old way to create thread globals was to put an underscore before and after the variable name: poof, instant global. The new way: call thread.getGlobalAddress( nameOfGlobal ). It does the same thing: puts _ on the beginning and end of nameOfGlobal and returns a string. Either way, the string can then be dereferenced like an address to get the global's value.

To create a global, first get the address, then dereference it and assign something to it, like this:

gMyGlobal = thread.getGlobalAddress( "myGlobal" );
gMyGlobal^ = "Hello, world!"

For an example, let's say that you have written a set of scripts which processes an XML file, and converts it into something else, like HTML or PDF. Different parts of the XML are processed by different scripts, but all of the scripts need access to the same two or three pieces of data (variables).

You could pass those variables from one script to another to another to another, but passing variables around costs time and memory, and if the values are large then this could be a significant problem. You could pass only the address of the values, but then you'd still have to remember to pass the addresses, and even passing addresses takes a little time and memory for every single call. You could put them somewhere in a database, but then you have to make sure that it's thread-safe (if you're writing a multi-threaded system), and you have to remember to clean up after yourself when you're done.

A thread-based global lets you set one value, and access it from any other scripts in the thread without having to pass it around. When the script that created the global finishes executing, the global is destroyed along with the script's local variables so you don't need to worry about cleaning up.

Watch Out

Two things to keep in mind about globals:

1. They go out of scope when the script that created the global returns to the caller.

2. You can refer to the global directly by name, like _myglobal_, but it doesn't always work as you'd expect. You're better off either assigning the result of thread.getGlobalAddress to a variable, or assigning the name (as a string) to the variable, and then dereferencing it. Like this:

gXmlData = thread.getGlobalAddress( "xmlData" )
dialog.alert( gXmlData^ )


gXmlData = "_xmlData_"
dialog.alert( gXmlData^ )

Otherwise, if you need to do anything with the global like add it to another value, things get confusing. For example, this works:

dialog.alert( _xmlData_ )

but this does not:

dialog.alert( "XML Data is: " + _xmlData_ )

I'm not entirely sure why that doesn't work, but it doesn't. If you've put a table into a global you won't have any problems since you can't add/subtract with tables anyway, but for consistency you should stick with the former method of accessing and using globals.

Page last updated: 5/2/2003

is Seth Dillingham's
personal web site.
More than the sum of my parts.