Subject: Re: [boost] Gauging interest in patch submissions
From: Philip Bennefall (philip_at_[hidden])
Date: 2011-09-28 13:04:34
----- Original Message -----
From: "Brett Lentz" <blentz_at_[hidden]>
Sent: Wednesday, September 28, 2011 5:48 PM
Subject: [boost] Gauging interest in patch submissions
Hi all -
I'm a new addition to the list. I joined because I wanted to get some
feedback on whether the Boost community is interested in accepting some
patches from another project.
The Phusion Passenger project is currently shipping a bundled version of
Boost with some custom modifications to suit their purposes.
I think their changes might benefit the wider Boost community, and I'd
like to see if the community agrees with me. Passenger uses the MIT
License, which I believe is compatible with Boost's submission requirements.
Small note: If I understand the MIT license correctly it requires that you
include the license text in binaries, which, if I'm not mistaken, is
something that the Boost license requirements mention explicitly as not
being desireable. Anyone please correct me if I am wrong on this.
So, I'll start off with a description of the changes and if there's
interest, I can post the actual patches for additional comment.
The changes are:
1. Adding an optional stack_size parameter to thread::start_thread()
This is useful in Passenger's case where they want to reduce the VM size
without requiring the user to hassle with ulimit settings on Linux.
Passenger spawns many threads rather than using a thread pool for
This change is, its current form, platform-specific, but I'm working on
correcting that, hopefully without a ton of ifdefs.
A big yes to that. I use a thread pool in several cases and lowering the
stack size would save me a lot of space. Thumbs up.
2. Adding backtrace and system_error_code support.
This adds additional exception information to boost::thread_exception,
boost::thread_resource_error, and boost::thread_interrupted that allows
Passenger to dump a full backtrace all the way up its stack.
This change is relatively straightforward and seems like it would
benefit a number of users.
I would certainly find this valuable, especially when debugging larger
applications. I do wonder whether it should be specific to thread
exceptions, though. As another poster said, perhaps in the Boost exception
Please let me know if I should post patches for one or both of these
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk