Vicente Botet <vicente.botet <at> wanadoo.fr> writes:
Geoff Shapiro wrote
I'd like to see in your example how you see a user incorporating thread attribute settings for non-portable attributes.
Here it is what I wrote: " The portable application needing some specific configuration can construct portable threads using the following schema
thread::thread_attributes attr; // set portable attributes // ... attr.set_stack_size(1000000) #if defined(BOOST_THREAD_PLATFORM_WIN32) // ... window version #elif defined(BOOST_THREAD_PLATFORM_PTHREAD) // ... pthread version pthread_attr_setschedpolicy(attr.get_native_handle(), SCHED_RR); #else #error "Boost threads unavailable on this platform" #endif thread th(attr, f,ctx); "
Isn't this enough clear?
Actually, it is perfectly clear. It wasn't clear to me at the time I posted because I hadn't read through the example carefully enough. Thanks for pointing this out.
2. It might be a good thing to be able to specify a default attribute set to be used in a constructor version not taking an attribute object reference (this is the current constructor).
The current constructor uses the default native attributes. Is this what you mean?
Not quite. I was bringing up the idea that a code implementation could instance a thread_attributes object and set it as a default attribute bundle. The current constructor would use this default set of attributes, if set, rather than rely upon the default native attributes. For me, the utility of having this is multiple: backward compatibility for a large code base already using the legacy constructor for threads, asserting a uniform default policy that is easily modified across all threads, not having to cope with differences in the default native behaviors in different environments, etc. In general, I really like your proposal and would like to see it go forward. Geoff