Rob Stewart <stewart <at> sig.com> writes:
From: David Abrahams <dave <at> boost-consulting.com>
You have to understand, the Boost.Threads specification was designed to become a standard, and as such it didn't include anything nonportable. That said, there's no reason we shouldn't expose the low-level thread IDs and document them in a special section on platform specifics.
If the platform specifics are kept from the portable interface -- through implementation magic -- then we get both properties.
Documentation must also mention what not to do via that non-portable mechanism. IOW, there are many things one can do via low level APIs that can break invariants, so restrictions must be placed upon what can be done or more interface is needed to allow the portable interface to adapt to the effects of the non-portable code path.
Another possibility is to provide another level of indirection. For example, boost::thread can have an accessor which returns a boost::platform_thread, which has the OS thread ID, plus member functions which mimic OS operations not reflected in the portable (boost::thread) API. The advantage of this approach is that boost::platform_thread member functions may be able to preserve invariants that otherwise might be broken if the user was allowed to manipulate the underlying OS thread ID itself, and if the coverage of the boost::platform_thread member functions is large enough, it might not even be necessary to expose the OS thread ID at all. Just a thought. Bob