-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/30/2011 01:11 PM, Vicente J. Botet Escriba wrote:

Le 30/11/11 17:13, Brett Lentz a écrit :

...

Patch and (very) rudimentary usage example is attached.

A couple months ago, I sent mail to the list looking to see if there's interest in getting some patches merged from Phusion Passenger. (See: http://marc.info/?t=131722868200003&r=1&w=2 )

So, here's the first patch I'd like to try to get committed. On pthread-based systems, it allows for the user to request a custom stack size.

This is useful in Passenger's case where they want to reduce the VM size without requiring the user to hassle with ulimit settings. Passenger spawns many threads rather than using a thread pool for performance reasons. As a result of this design decision, they also need the ability to tune the stack size.

Ticket #5956 already exists for this patch. I've verified that the patch works against the current (1.49) codebase out of SVN.

What next steps need to be taken before this is committed?

Hi,

I don't know. I have submitted a more generic patch *3 years* ago and there is no response yet. https://svn.boost.org/trac/boost/ticket/2741 :proposal to manage portable and non portable thread attributes

Btw, could you take a look at the ticket and tell me what do you think of my proposal?

Best, Vicente

I can definitely see the benefit to a more generic solution. I'm not opposed to it in principle. Unfortunately, I'm probably not the best person to comment on the pros and cons of your patch versus the one I'm pushing. My skills in C++ are pretty poor. I'm mostly acting as a liaison and steward for these patches. I'm trying to facilitate allowing Passenger to compile against a non-forked version of Boost. To do that, there's a few key elements of their fork that need to be merged into the upstream Boost. So, the sooner I can get movement on this, the better. - -- - ---Brett. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO1n+WAAoJEEAzW/nB31+3SMQH/jmXVVAFTiDAAU0kgev3onJA DusPsBxP3gDUWYnkZ/9gAZ/B0LnSr8Bbxu/QQYrqsQxtEigVXtS3mlcIfTyfFYoQ 7S7aDRwR/SgKS+doGkHNQ3Y8+xQP3ly9bTdT5zDl9lU8CAY0uPkONIAhnRQJalne X2Sj+9lLSJt7EMKnTwtqrJaciIUE3pLC0LDkjn0GrB33kSTU5N8GFr7UvAYoqBXr DU2CKNQM7Nacuoh2XUdwZzHWOlfRTuEmAdbMlqAEIOinNsL23rIAVCMVd8ZPrSF6 g1CZ4WiLmpbKM2vykAspTn8szfxdrlg3XQhMspYECzV7pQ5OHR7XFHireM74WcM= =40+3 -----END PGP SIGNATURE-----

On 30/11/11 21:47, Vicente J. Botet Escriba wrote:

The main problem with the Boost.Thread features is that they go after the resolution of the long list of bugs. I guess that Anthony needs some co-maintainers to reduce this long list.

Fancy taking on the task Vicente? Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

Vicente J. Botet Escriba <vicente.botet <at> wanadoo.fr> writes:

I don't know. I have submitted a more generic patch *3 years* ago and there is no response yet. https://svn.boost.org/trac/boost/ticket/2741 :proposal to manage portable and non portable thread attributes

Btw, could you take a look at the ticket and tell me what do you think of my proposal?

Vicente, I have looked at your proposal and I like the direction you headed with that set of patches. There was a recent request for changes to boost::thread to allow priority inheritance on thread creation (pthread environments) and your proposal would cover that with no problem. I'd like to see in your example how you see a user incorporating thread attribute settings for non-portable attributes. Other thoughts that could be considered: 1. Would thread priority setting be considered a portable or non-portable attribute? There does seem to be quite a bit of variation in this amongst different environments. It would be nice if it could be generalized and reconciled amongst the different environments. 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). Geoff

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

Geoff Shapiro <gshapiro@flir.com> wrote in news:loom.20111201T191114-176 @post.gmane.org:

I'd like to see in your example how you see a user incorporating thread attribute settings for non-portable attributes.

Something I find useful under Win32 is the ability to set a thread's name so that it can be easily identified in the debugger. This attribute is also present in Linux and MacOS, but implemented slightly differently in each case, with different limitations. This ticket for the wxWidgets framework provides links to several resources about this as well as some discussion about the differences in the platform implementations: http://trac.wxwidgets.org/ticket/11245

Le 02/12/11 17:58, Geoff Shapiro a écrit :

Kenneth Porter<shiva.blacklist<at> sewingwitch.com> writes:

...

Geoff Shapiro<gshapiro<at> flir.com> wrote in news:loom.20111201T191114-176 @post.gmane.org:

...

I'd like to see in your example how you see a user incorporating thread attribute settings for non-portable attributes. Something I find useful under Win32 is the ability to set a thread's name so that it can be easily identified in the debugger. This attribute is also present in Linux and MacOS, but implemented slightly differently in each case, with different limitations.

This ticket for the wxWidgets framework provides links to several resources about this as well as some discussion about the differences in the platform implementations:

http://trac.wxwidgets.org/ticket/11245 I had the same need in my project (where win32 is only one of the environments it runs in), and also implemented a solution. Thanks for the link which I will look at later today.

While I believe the solution I arrived at is decent, I would have liked to see this type of thing considered in the boost interfaces.

Me too, but the problem is that these attributes are not portable, so it will be quite confusing to provide them for only the platform that could support them. First I would like to open the door to be able to set attributes that must be there at the creation of the thread. For the non portable part, you could always use the native_handle and the native interface. Best, Vicente

Kenneth Porter <shiva.blacklist <at> sewingwitch.com> writes:

"Vicente J. Botet Escriba" <vicente.botet <at> wanadoo.fr> wrote in news:4ED912A3.5010206 <at> wanadoo.fr:

...

Me too, but the problem is that these attributes are not portable, so it will be quite confusing to provide them for only the platform that could support them.

While the name feature is not identical across platforms, several of the platforms do support the idea, so having a generic way to set the name is still desirable for platforms that do support it. Since this is just a chunk of memory in the kernel, it could be easily emulated on platforms that lack it.

Exactly. Also, while the posix standard (so far as I can tell) has not defined a pthread_attr_{set,get}name set of interfaces, the VxWorks posix library implementation has. The requirement, of course, is that the name be available at thread creation. Unless support is included up front in the attributes class Vincente proposes, it won't be achievable in that environment. Having the support in the attributes class would be fine, even in those platforms where setting name is done after creation. The boost thread implementation could set the name after successful thread creation. Geoff