Boost logo

Boost :

Subject: Re: [boost] [thread] [repost] proposal to manage portable and non portable thread attributes
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2009-01-21 16:58:53


Perhaps it's possible to come up with a system of hints (stack size is
a good example I guess)?

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode

On Wed, Jan 21, 2009 at 1:01 PM, vicente.botet <vicente.botet_at_[hidden]> wrote:
> Hello, I first posted this six months ago, allow me to repost just in
> case it went unnoticed:
>
> Note that I don't know the Windows platform, so I'm unable to tell which attributes are portable.
> What it is important is to be as close as possible to the user needs even if all the interfaces are not portable. I supose this was the intent of the native_handle_type found already on the ++0x and the Thread library.
>
> My old proposal was surely not the best one, but I realy think the needs are yet there. Applications needs sometimes to use non portable interfaces to get the better from the system at hand. The current C++0x and Boost.Thread allows to get native_handle_type of a thread and a mutex but don't allows to set the non portable atributes at the creation, in particular for the thread attributes.
>
> I'm no more interested you analize my old proposal, but you consider the needs of the users and see how we can give them what they need.
>
> Thanks,
> Vicente
>
> ----- Original Message -----
> From: "vicente.botet" <vicente.botet_at_[hidden]>
> To: <boost_at_[hidden]>
> Sent: Thursday, June 19, 2008 11:01 PM
> Subject: [boost] [thread] proposal to manage portable and non portablethread attributes
>
>
>>
>> Hello,
>>
>> Boost.thread has already a non portable interface to get the thread handle
>> class thread {
>> public:
>> ...
>> typedef np_native_handle_type native_handle_type;
>> native_handle_type native_handle();
>> ...
>> };
>>
>> Boost.Thread do not allow to pass thread attributes on the thread
>> constructor. I supose that this is due to portable issues. Could we
>> identifiy which attributes are portable and which one not?
>>
>> The portable attributes (as stack size, ...) can be grouped on a
>> thread_attributes class.
>>
>> In order to be able to pass whatever attribute to the thread constructor we
>> can add the setting of non portable attributes to this thread_attributes
>> class, and making the thread constructor take a thread_attributes in
>> addition to the existing parameters.
>>
>> class thread {
>> public:
>> class thread_attributes {
>> // portable attributes
>>
>> public:
>> // set/get of attributes
>> // ..
>> #if defined(BOOST_THREAD_PLATFORM_WIN32)
>> // ... window version
>> #elif defined(BOOST_THREAD_PLATFORM_PTHREAD)
>> private:
>> pthread_attr_t native_attributes;
>> public:
>> set_np_attributes(const pthread_attr_t* h);
>> // ... other
>> #else
>> #error "Boost threads unavailable on this platform"
>> #endif
>> };
>> thread(const thread_attributes*p, F f,A1 a1);
>> ...
>>
>> };
>>
>> The portable application needing some specific configuration can construct
>> portable threads using the following schema
>>
>> thread::thread_attributes attr;
>> // set portable attributes
>> // ...
>> #if defined(BOOST_THREAD_PLATFORM_WIN32)
>> // ... window version
>> #elif defined(BOOST_THREAD_PLATFORM_PTHREAD)
>> // ... pthread version
>> pthread_attr_t native_attributes;
>> pthread_attr_init(&native_attributes);
>> pthread_attr_setstacksize(&native_attributes, 1000000);
>> attr.set_np_attributes(&native_attributes);
>> #else
>> #error "Boost threads unavailable on this platform"
>> #endif
>> thread th(attr, f,ctx);
>>
>> What do you think?
>>
>> Vicente
>>
>>
>> _______________________________________________
>> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk