From: Bob Bell (belvis_at_[hidden])
Date: 2005-03-07 19:34:03
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk