Navigation:  Programming Cookbook > External Interfacing > Overlapped Calls >

Thread Affinity

Previous pageReturn to chapter overviewNext page

The threads used to perform overlapped calls are allocated on the first attempt to make an overlapped call from a particular Smalltalk Process . Once a thread has been allocated to a Process, it remains associated with that Process until the Process is terminated. Note that this differs from versions of Dolphin prior to 6.0; in older versions the threads were allocated from a pool.

A Smalltalk Process corresponds more closely to a "thread" than a "process" in operating system terms, however for historical reasons the class is still called Process.

The association between Process and thread is useful when calling APIs that have thread affinity, in that it means all calls from the same Process will be on the same thread. Many APIs and libraries, including the C runtime library and Win32, use "global" variables that are actually thread local variables to report extended error information. For example many C functions set the errno variable, and most Win32 API calls set a thread local variable accessed by GetLastError(), when they fail. These particular examples are so important that they are exposed through accessor methods on Process, namely errno and lastError respectively.

Each thread allocated consumes operating system resources for its stack, context information, etc. There is currently no way to disassociate a thread from a Process and release its resources, other than terminating the Smalltalk Process. Thus the number of Smalltalk Process objects performing overlapped calls that can exist simultaneously is limited by the maximum number of threads that the operating system can practically support in one process.

The theoretical limit on the maximum number of threads in one process is based on the default allocation of 1Mb of virtual address space for the stack. This implies a theoretical maximum of about 2000 threads per process, but in fact the practical limit is much lower than this. It is not generally advisable to run more than a couple of hundred threads in any one process.

If your application is a server (such as a web server) that has to support many hundreds of clients, and you are using overlapped calls from processes servicing those users, you may have to consider implementing some form of Process pooling architecture, rather than allocating one Smalltalk Process per user. You will run into a limitation with Smalltalk Process objects too, since these also reserve a chunk of virtual address space for the stack (128Kb by default), but it will come much sooner where overlapped call threads are in use.