Hi,

At February 14, 2004, 09:02, Moravecz László wrote:

> I have catched out above example code from Borland.

> The 'threadvar' is enought for this restriction?

Not when using thread pooling. If you read the paragraph following
the one you quoted, you'll see why.

[Start quote...]
Do not use thread-local global variables to simulate global variables.
SuperServer implements a sort of thread pooling mechanism, to share
threads among all the client connections. It is likely that if a given
client executes a UDF twice, that each execution is not executed in
the context of the same thread. Therefore, you cannot depend on
thread-local variables keeping values from one execution of the UDF to
the next for a given client.
[...End quote]

Read the following text from Microsoft's Platform SDK(Feb. 2003), this
confirms what is written in the above paragraph:
[Start quote...]
To use thread pooling, the work items and all the functions they call
must be thread-pool safe. A safe function does not assume that thread
executing it is a dedicated or persistent thread. In general, you
should avoid using thread local storage and queueing asynchronous
calls that require a persistent thread, such as the
RegNotifyChangeKeyValue function. However, such functions can be
queued to a persistent worker thread using QueueUserWorkItem with the
WT_EXECUTEINPERSISTENTTHREAD option.
[...End quote]

And, threadvar is to declare thread local storage variables.

What is basically said, is that a UDF must be self contained and not
rely on external variables. If you really want a value to persist
between UDF calls, or used between multiple UDFs, then use an external
storage device(i.e.: a text file).

--
Best regards,
Daniel Rail
Senior System Engineer
ACCRA Group Inc. (www.accra.ca)
ACCRA Med Software Inc. (www.filopto.com)