Enabling and Disabling of SMT

The special value of 0 for Region Size specifies that SMT is to be disabled. Disabling SMT removes it from the Xserver causing it not to be available for any transports. Any non-zero Region Size enables SMT on the Xserver. The default Region Size for a diskless Xserver is zero (disabling SMT from the Xserver) to minimize the access of files across the network. The default Region Size for non-siskless Xserver is 100000 (which is rounded to 0x19000).

____________________________________________________________________________________

Begin Note for Programmers:

X Applications which call fork(), and access the same display structure from both the parent and the child cannot be expected to operate reliably without extreme care (if at all), whether or not SMT is used. However, SMT is more sensitive to this than UDS. The problem is quite similar to stdio, where fflush() must be used to assure that data makes it from the buffer onto the file exactly once.

Similarly to stdio's use of fflush(), XFlush() (not _XFlush()) must be called immediately before any

fork() call that will be accessing the display from both the parent and child, as well as any time control is transferred between the parent and child, or vice-versa. (Calls to fork() which immediately do an exec() are not a problem.)

The SMT library code attempts to detect improper use of display connections after a fork, and issues a warning at runtime. However, not all such usages can be detected. Symptoms include reporting the error, and hanging applications.

Also, because the parent and child might read from the same display connection (either replies or events) the library can detect inconsistent sequence numbers, which it will report. It will attempt to recover from such errors, but depending on what the application has done, recovery cannot always be successful.

Only for R5 Applications

SMT requires a change to an internal interface with the X library. In theory, no application should be calling this interface, but some applications, including at least one X test suite, are known to call it. The interface is _XConnectDisplay. Applications using it directly may not be able to use SMT for the display specified, and must add an extra (ninth) parameter, which is the address of an integer:

int dummy;

_XConnectDisplay(..., &dummy);

Symptoms include both damaged data and core dumps.

(There was an earlier HP Shared Memory Transport, which this one replaces. It used the same parameter, so it may be the case that any such calls have already been fixed.)

This problem does not occur in the R6 library.

End Note for Programmers

____________________________________________________________________________________

Page 37

Graphics Administration Guide for HP-UX 10.20