Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
--- Comment #64 from Mohammed Morsi <mmorsi(a)redhat.com> 2010-09-14 12:53:29 EDT ---
(In reply to comment #63)
Passenger 3's Boost is actually based on 1.42.0. A lot of API
happened between Boost 1.35 and 1.42. I believe it's impossible to support
multiple Boost versions without making our code a mess with #ifdefs everywhere.
We only support one specific version of Boost for the time being: the one we
use during development.
Can you please elaborate on this. Looking at the passenger repository, it seems
boost is still marked as being on version 1.35
and the last commit I see relating to 'updating boost' is the update to 1.35
At what point did you update to 1.42? In any case for this submission, boost is
still at 1.35 which I hope isn't so incompatible with 1.44 (shipping on F14)
that it won't compile against it.
The condition_variable and mutex error checks do not retry on all errors: they
only retry on EINTR. BOOST_VERIFY aborts even on EINTR but EINTR is usually not
fatal, it just means you need to try later. This issue bit us on one of our
customers' production systems.
This is good to know that this was to solve an edge case on a production
system. Which OS was this customer running btw? If it something other than
Linux (and maybe even if it's another distro) we might not run into this onto
Fedora and thus this can be omitted.
Exception hierarchy change: yes they're informational. If a thread fails to
spawn (i.e. thread_resource_error is thrown) then we'll want to show a
backtrace. This is not possible without patching Boost and changing the ABI.
Please do not remove TRACE_POINTs. They're an essential part of our system
inspection features. Right now it's possible to query the backtrace of all
threads in Phusion Passenger during runtime thanks to the TRACE_POINTs. If you
get rid of that then our users will lose their ability to see what's going on
and will introduce a lot of headaches when things go wrong.
I would like to include this (and everything else), but it looks like there is
no way to include passenger in Fedora without this being removed (eg passenger
needs to work against the stock boost). So its either remove this debugging
stuff or not ship passenger at all. Like you said in a previous comment, if
anyone wants any of these features I'm removing they can simply get passenger
Thread constructor: it is not unnecessary, we do this intentionally to reduce
the VM size. We create a lot of threads. The default thread stack size on Linux
is 8 MB, so unless we reduce the stack sizes we can't create many threads and
the VM size will grow very large, giving users the impression that we're memory
Have you guys ever considered using thread pools? Launching many threads
indiscriminately is often considered bad practice, and you may get a
performance boost by making use of a pool. Regardless its good to know that
this is simply to make the memory footprint smaller, and it should work without
this. Just curious is there any way to reduce the default thread stack size,
systemwide lets say, without modifying/recompiling every program?
I'm starting to hack at this to see if I can get it working. Based on your
response the only thing that makes me not sure if this will work is the
discrepancy between boost versions, but we'll just see if that poses and issue.
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.