The list isn't that long. What distinguishes those interfaces is that they
can't be implemented on top of, e.g., the stdio implementation. The original
question, as I understood it, was whether the general architecture of
Windows was a reasonable fit for a POSIX threads implementation. Most of the
library can be implemented without unwarranted chumminess with the
underlying implementation, and the remaining pieces--with signals being the
biggest question mark--would appear to require only minimal cooperation by
the vendor.
Not that I believe C1x should adopt pthreads, mind you. Also, the proposal
was qualified--it suggested adopting a _subset_ of pthreads.
There are two proposals that I'm aware of, neither of which can be
accurately described as a "subset of pthreads". The official proposal is
for changes to the language and a set of new library functions that
could be implemented as thin wrappers for pthreads functions, but are
sufficiently generic in their definitions that they could alternatively
be implemented as thin wrappers for other threading systems.
The second proposal has not been officially made, but has been suggested
in a number of forms in this forum. That proposal is that the entire
pthreads specification from POSIX should be inserted, by reference, into
the C standard. While not explicitly stated, the implications have been
that it would need little or no additional wording would be needed,
beyond the statement that it has been so incorporated.
The list of pthreads features which have not been implemented in Windows
is an argument in favor of the official proposal, over the unofficial
one. In the unlikely event that the second proposal were accepted, a
conforming implementation of C running under Windows would be required
to implement all of the items on that list. How difficult would that be?
If Microsoft has not even attempted to implement them, I imagine it
would be pretty difficult.
The fact that even those features which are available, are available
only in the POSIX Subsystem of Windows, and not for native Windows
programs, is another such argument. If I understand it correctly, the
official proposal defines a system that could be made available even for
native Windows programs.