[thread] proposal to manage portable and non portable thread 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
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@wanadoo.fr> To: <boost@lists.boost.org> Sent: Thursday, June 19, 2008 11:01 PM Subject: [boost] [thread] proposal to manage portable and non portablethread attributes
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@wanadoo.fr> wrote:
vicente.botet wrote:
Yes. In particular you can't specify the stack size, and there is no way to change this after creation once the native_handle is available. See this thread: http://thread.gmane.org/gmane.comp.lib.boost.devel/168678 Although I can't find it now, I recall also reading a message from Howard Hinnant where he said that this had been put to the standards committee but had not got anywhere. I think Howard was suggesting that other "interested parties" should put together a proposal in the hope that they would have more luck (but this is a while ago now so I may not be remembering right). To me, since I had other problems with the std::thread proposal (i.e. their choice of cancellation semantics [*]), and because I only care about POSIX, it was simplest just to write my own thread class. [*] If there's anyone else using glibc's pthread cancellation and C++ destructors I would always be interested to talk.... Phil.
participants (3)
-
Emil Dotchevski -
Phil Endecott -
vicente.botet