Back
Home
Up
Next

Changed UDF functionality.

    Since IB4.2 on Windows, IB was called SuperServer, because it's a single process with multiple threads. In some other platforms, the same architecture was applied to IB later. The memory that's allocated and released in UDFs in a multi-threaded process requires different techniques and a different declaration. In the classic architecture, where one separate process serves the requests of each user, when that process terminates, the memory requested by an UDF is returned. Also, since each process has a single thread, race conditions between threads doesn't exist and reentrancy is not an issue.

In a multi-threaded architecture, the main process only dies when IB is terminated and threads share a global space, each one being scheduled by the operating system. Hence, memory alocated dynamically wouldn't be freed until IBServer itself finishes and UDFs can't use static memory without protection, because reentrancy exists and it would introduce mysterious crashes or mangled results. If a function allocates static memory, all threads using the same function can see the same chunk of memory.

The solution was to add the keyword FREE_IT to allow users to write thread-safe UDF functions without memory leaks, whenever an UDF returns a value by reference to dynamically allocated memory. The call to be used with C++ is malloc and with Delphi, sysalloc. The syntax became:

DECLARE EXTERNAL FUNCTION name [ <datatype> | CSTRING ( int)
[, <datatype> | CSTRING ( int) ...]]
RETURNS { <datatype> [BY VALUE] | CSTRING ( int)} [FREE_IT]
ENTRY_POINT "<entryname>"
MODULE_NAME "<modulename>";

However, there're still some tough issues: IB was compiled with MSVC, so people writing UDFs with BC++ were using a different dynamic memory manager and also, other problems have been reported regarding the use of FREE_IT. There's a workaround: an undocumented syntax that allows a parameter to be defined as the the return, so the server allocates and frees the parameter. This overcomes the problem of using different compilers, since the server will inspect the parameter marked as return, get its value and then free its memory. The complete syntax, that hopefully will appear in IB6's final documentation, is:

DECLARE EXTERNAL FUNCTION name [ <datatype> | CSTRING ( int)
[, <datatype> | CSTRING ( int) ...]]
RETURNS { { <datatype> [BY VALUE] | CSTRING ( int)} [FREE_IT]
| PARAMETER int_pos }
ENTRY_POINT "<entryname>"
MODULE_NAME "<modulename>";

Where this "int_pos" is the position of one of the arguments, starting from one. This parameter cannot be specified with the FREE_IT keyword, because parameters are by definition managed by the server and this is indeed the idea: to avoid the subtleties of FREE_IT.

 

This page was last updated on 2001-02-15 19:29:09