© 2001 International Business Machines Corporation. All rights reserved.

Introduction

Functions created by the DataBlade are assigned to a Virtual Processor (VP) class. The class assigned to the function affects its performance characteristics and what operating system interactions the function is restricted from using. Generally, the more restrictive the VP class, the more efficient the performance of the function will be. A singularly definitive list of system calls to be avoided can not be provided, however, because it would need to change for different versions of operating systems and different types of operating systems. Additionally, the implementation of the VPs is different between UNIX and NT. On UNIX, the VPs are implemented as separate processes, while on NT each VP is an NT-thread of a common process. This difference results in some system calls being acceptable on NT which are not acceptable on UNIX. However there are also differences between the UNIX handling of shared objects and NT's handling of DLLs which make these distinctions complex. Additionally, it is assumed that most companies will want their DataBlade code to be portable between UNIX and NT. In the interest of simplicity, a single list is presented with NT specific calls listed in brackets. NT specific comments are summarized at the end of the paper.

On UNIX, to check if an undesired system call has been included it is suggested you use nm and ldd. nm will list the unresolved references used in a shared object. ldd will list the dynamic dependencies from a shared object. Given the .bld shared object produced for a DataBlade module, you should check the unresolved references for it, and recursively for all its dependencies, to see if they include a system call which violates the VP desired.

On NT, the DUMPBIN command with the /IMPORTS option will give the equivalent information.

There are three VP classes used for DataBlade functions:

• CPU VP
• User-Defined VP
• No-Yield User-Defined VP

Back to top

CPU VP

All routines which do not run explicitly in a user-defined VP are run in the CPU class VP by default. This is the most restrictive VP class. The following types system calls must not be used in a CPU VP.

• Calls which perform blocking IO (open, read, accept, bind, etc.)
• Calls which manipulate signals to processes (signal, alarm, beep, etc.)
• Calls which modify the systems security (setuid, seteuid, setruid, setgid, setegid, setrgid, etc.)
• Calls which allocate or free memory (malloc, calloc, realloc, free,etc.)
• Calls which initiate OS provided threads (pthread_create, thr_create, etc.)
• Calls which initiate or halt system processes (fork, exec, exit, system, popen, etc.)
• Calls which change the current working directory
• Calls which change the process' global state (gethostent, gethostbyaddr, gethostbyname, sethostent, endhostent, etc.)
• Calls which modify the process' data segment size (brk, sbrk, etc.)
• Calls which modify shared memory segments (shmat, etc.)
• Calls which modify the dynamic linker's run-time environment (dlopen, dlsym, dlerror, dlclose, etc.) [LoadLibrary, etc.]

Additionally the code must not update any global and/or static variables.

The execution of a server-side DataBlade function should not take excessive amount of CPU time (> 0.1 second) without calling mi_yield().

Back to top

User-Defined VP

If the DataBlade module uses a prefix registered with Informix, then the name of a User-Defined VP is required to begin with the DataBlade's prefix.

All of the restrictions of the CPU VP apply except for those involving blocking IO. This VP is most often used, if it is not practical to rewrite the file system activity using the LIBDMI interface.

Back to top

No-Yield User-Defined VP

All of the restrictions of the User-Defined VP apply except for the use of global and/or static variables. This VP is most often used if the supporting code is not designed to handle concurrency issues.

NT specific comments:

DataBlade must use either the MT or static versions of the system libraries.

While NT developers should not call malloc and free directly, their occurrence in the binary from the use of MT dlls is considered safe.

The following actions are allowed on NT providing that they do not interfere with the shared memory model which IDS/UD uses:

DataBlades may create additional threads or processes

DataBlade may use shared memory for interprocess communication.

UNIX specific comments:

On Solaris, /usr/ucb/ld is a shell script which ends up calling /usr/ccs/bin/ld with modifications to make it "compatible" with the BSD package. These modifications force the BSD libraries and routines to be included BEFORE the base OS libraries and routines. Since the BSD version of libc includes sockets, unlike the ccs version, the following libs are added:

 
-lucb -lresolv -lsocket -lnsl -lelf 

For this reason, all DataBlades should be linked using /usr/ccs/bin/ld and NOT /usr/ucb/ld

About the authors

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• CPU VP
• User-Defined VP
• No-Yield User-Defined VP
• About the authors
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into Information Management on developerWorks

DB2 pureScale

See how true transparent scaling architecture can be achieved on distributed platforms

Special offers