----- Original Message ----- From: "Brett Lentz" <blentz@redhat.com> To: <boost@lists.boost.org> 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 performance reasons. 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 class itself? Please let me know if I should post patches for one or both of these changes. ---Brett.