Re: [boost] [thread] patch to allow custom stack size.

Subject: Re: [boost] [thread] patch to allow custom stack size.
From: Geoff Shapiro (gshapiro_at_[hidden])
Date: 2011-12-02 11:54:26

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