Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
--- Comment #74 from Mohammed Morsi <mmorsi(a)redhat.com> 2010-09-15 16:33:58 EDT ---
(In reply to comment #72)
The point of the modification was to have Boost.Thread itself throw
that are derived from thread_exception. Making a seperate
tracable_thread_exception won't solve that problem. But, as I've stated
earlier, there are fundamental packaging policy disagreements between us and I
believe it's easier to maintain the status quo.
Can't you simply catch the Boost Thread exceptions, and in the error handler
throw your own custom exceptions? You can interpret the thread errors in your
catch blocks and add as much debugging information as you need there. I'm
actually surprised that hacking boost took less time than doing it this way. I
suppose if you don't know all the boost thread exceptions, you'd want the
backtraces all the way though boost, but this doesn't seem like the best
Also what environments are you passenger on. It may be more than Linux/g++ but
if it isn't doesn't gcc have some non-standard means of obtaining backtrace
information for c++ exceptions?
I think everyone loses out with the status quo. There are Linux users who
_must_ use rpm / yum to install software on their systems, and using gem is not
an option. Thus you lose potential users of your software and we lose another
supported / tested deployment scenario. It would be great if we can all work
together to find and develop and acceptable solution that works for everyone. I
understand that time is very tight nowadays, but this is why we're volunteering
to help come up with and develop a solution.
(btw no flamewars here please, everyone is right for their own reasons, just
need to come up with the right solution)
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.