Boost logo

Boost :

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2007-10-10 20:17:49

On Oct 10, 2007, at 7:23 PM, Aaron W. LaFramboise wrote:

> Howard Hinnant wrote:
>> The only suggestion I have here, from a standards point of view, is
>> for the standard to anticipate and support user-defined mutexes/locks
>> in the easiest way possible so that libraries such as boost can
>> easily
>> build upon the standard foundation. This philosophical foundation is
>> in the standard-proposed document. Whether or not we've actually
>> achieved this goal is a separate question. ;-)
> Is there a summary somewhere regarding the extensibility features of
> the
> threading library?
> In particular, is this threading library you're standardizing going to
> create threading objects that hide their thread handle such that they
> can't be extended to work with custom multiplexers?
> [I am horribly concerned by the ever-increasing trend to write
> concrete-style components that support only least-common-denominator
> system features, with no possibly way to extend them due to
> inability to
> 'get at' some inner handle. Boost filesystem, Boost thread, iostream
> all do this, making it impossible for even a completely normal vanilla
> single-threaded GUI program to be able to safely use them (due to the
> fact they might block, and there's no way to multiplex them with the
> GUI, despite the fact the OS would be able to do this).
> The net effect is that these style of components are mostly useless to
> most modern single-threaded applications writers. I am hoping this
> threading library you are working on is something I will actually be
> able to use, and not just something made for terminal-based POSIX
> systems.]

I hope you'll be able to use it too. The current wording has:

class thread
     native_handle_type native_handle();

which I believe may address your concerns (not 100% positive). On a
POSIX system this might return a pthread_t. The idea is to give you
sufficient rope (hang or save, your choice). That being said, I seem
to remember some concerns over this feature and can not at this point
firmly establish its presence in the final draft (just too many balls
in the air).


Boost list run by bdawes at, gregod at, cpdaniel at, john at