customer must modify the sample code to provide the required service or function.
porting kit and hosts the software on one of the supported platforms.
of the software. Although the porting kits are more flexible and usually have more features, the
executable form can give a good idea of quality, capability, and performance.
example, although we use Berkeley sockets for IPC, a customer might choose to use pipes,
STREAMS, message passing, or other mechanisms. These decisions can have a radical affect
on performance.
customer can use the porting kit to host the software on a multiprocessor platform, or using
operating systems we do not support directly. Please consult the porting kit documentation for a
better idea of the options available with a product.
kits support threading and reentrant code, we do not use it in our own executable forms.)
this purpose, all resources of a single type are grouped together. For instance, a wait for any
single disk file might block execution of a process which needs a different disk file. The
executable forms of the software do not implement the parallelism available in the porting kit.
are used. The executable code does not distinguish between local and remote files, so a network
delay might temporarily block access to a local file.)
there may be multiple requests outstanding from one or more user application processes. User
applications, unlike the executable code we provide, may be threaded. If there is no contention
for resources, then the outstanding requests may be processed in parallel.