If Boost::threads is on topic (and I think it should be), it is kind
of hard to rule out specific threading APIs, since the guts of the
boost library deal with that.
Discussion of how to implement the Boost library on a particular
system wouldn't be on topic, I don't think. But Boost tries to
be (and generally is) fairly portable; you can use the Boost
library on Windows or on Unix.
It seems like it would be a lot simpler if we draw the line at
C++. If a post doesn't have any clear connection to C++, I
think its reasonable to ask why they posted to this newsgroup.
The problem is defining C++. The classical criterion is that if
the answer would be the same in all languages, but would vary
from one platform to the next, it's off topic, but if the answer
would be different in other languages, but be the same for most
implementations of C++, it's on topic.
There are definitely threading issues which are purely C++, and
are on topic here (e.g. synchronization requirements for the
initialization of a local static variable). There are
definitely threading issues which aren't (e.g. anything
concerning a platform specific API). Most of the threading
issues fall somewhere inbetween---there are a lot, for example,
which would be the same for more or less any language, but which
are also platform independent. Over all, I'm in favor of
accepting them, if for no other reason than that the standards
committee has decided to add threading to the next version of
C++, and is actively discussing them as well.
In this particular case, of course, the Boost interface is
certainly relevant---it's independent of the system you're using
(as long as you're under Windows or Unix, at least), and it is
definitly only a C++ issue.
