background image
Tech Note #44: Using Executable Programs
1998 Bionic Buffalo Corporation; All Rights Reserved.
              1 October 1998
3 of 4
Perform the requested operation
The application libraries include sample source code to build these service processes. The
customer must modify the sample code to provide the required service or function.
Evaluating the Porting Kits
The executable software we license is built from our own porting kits. Bionic Buffalo takes a
porting kit and hosts the software on one of the supported platforms.
Customers who wish to evaluate the porting kits may do so by trying out the executable versions
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.
The porting kits allow the customer to make hosting decisions differently than we have. For
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.
Porting kits allow other options which we do not support in our executable versions. A
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.
Processes and Threads
Typically, each executable product runs as several different processes. (Although the porting
kits support threading and reentrant code, we do not use it in our own executable forms.)
The architecture is done so that blocking occurs only when waiting for system resources. For
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.
(Note that this grouping of resources may cause delays when networked or remote file systems
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.)
The application libraries do not implement explicit threading. However, they are thread-safe, so
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.
Some APIs directly support asynchronous request processing. As examples: