DCEThreads

DCE/RPC was under development, but the POSIX committee had not finalised POSIX threads at the time. The Open Group had to make a decision about which to use, and the final POSIX threads were different from their selection.

POSIX Draft 4 threads were limited to begin with (the final standard fixed these). Microsoft adopted DCE/RPC wholesale in Windows NT as MSRPC and also in DCOM. Most of the stability and reliability problems that programmers associate with DCOM services - especially memory leaks, exception handling problems and thread cancellation stability issues - can be traced back to the use of POSIX Draft 4 threads.

DCE/RPC is sufficiently complex that the issue of updating it to solve and modernise the POSIX Draft 4 threading problem requires highly skilled and highly specific programming knowledge. Consequently, despite its capacities, the reference implementation of DCE/RPC has been held up due to a lack of information and resources.

The key difference between POSIX Draft 4 threads and the final POSIX threads specification, aside from a number of functions being interruptible where others are not, is thread cancellation. DCE/RPC utilises thread cancellation to propagate signals across the "Remote" of RPC, such that for example a client application terminating a thread results in its corresponding thread on the server also being terminated in the same way. The final POSIX specification does not include such sophisticated cancellation methodology, and, given the difficulties that the Unix vendors had in correctly implementing the POSIX threads specification, it was removed.

Linux, since the introduction of NPTL and the Linux 2.6 kernel, has proper support for thread cancellation.

DCEThreads now only realistically exists as an emulation layer.