HP DCE/9000 Application Development Tools for HP-UX 11i Release Note

23
HP DCE/9000 Version 1.8 Application Development Tools for HP-UX 11i Release Note
Developing DCE Applications with HP DCE/9000
export RPC_SUPPORTED_NETADDRS=ip:10.3.2.1
will force any servers started in the current shell to support only the addresses associated
with the name myhost and the network address 10.3.2.1.
Calling exec() from a DCE Application
Care must be used when calling exec() from a DCE application. HP DCE Threads sometimes
sets open file descriptors to non-blocking mode, so that I/O calls block only the calling thread,
not the entire process. This occurs unbeknownst to the application itself. HP provides
wrappers for the exec() family of calls that, among other things, resets file descriptors to
blocking mode if they were set non-blocking by HP DCE Threads and not the application.
For file descriptors that were inherited across fork(), this also has the effect of resetting the
file descriptor to blocking mode in the parent as well as the child. If the parent is a threaded
program, it can cause the parent to hang due to a blocking I/O call.
There are two possible work-arounds:
• If the process will not need the open file descriptor, set the close-on-exec flag for the file
prior to calling exec(). The file descriptor will not be reset in this case.
• Avoid using the exec() wrapper; call exec() directly instead. This is accomplished by
undefining the appropriate macro, for example: #undef execle.
Note that if the exec() wrapper is circumvented, the new process may inherit file descriptors
that are unexpectedly set non-blocking; some signals may be unexpectedly ignored or not
ignored; and, if exec() is called without first calling fork(), the new process will probably be
killed by SIGVTALRM as soon as it begins execution.
Process Forking
Process forking from within RPC applications that use the connection-oriented (TCP/IP) RPC
protocol is not supported.
While it is generally safe for an application to perform a fork followed immediately by an
exec(), the following sequence may not work for TCP/IP RPC programs:
• The TCP/IP RPC process forks.
• The child process tries to use RPC over the TCP/IP protocol before the exec().
Process forking from within RPC applications that use the connectionless protocol (UDP/IP) is
supported, with the following restrictions:
• For client-side applications, the UDP/IP protocol is fork safe. It is the responsibility of the
application developer to ensure that all other application threads are capable of crossing
forks safely.