[Bug 470696] Review Request: rubygem-passenger - Passenger Ruby on Rails deployment system

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=470696

Mohammed Morsi <mmorsi at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mmorsi at redhat.com

--- Comment #62 from Mohammed Morsi <mmorsi at redhat.com> 2010-09-13 17:33:56 EDT ---
I just spent a little while going through this and trying to figure out what
exactly would need to be done to get passenger working with the stock boost in
Fedora. The following are issues we may run into:


Issues which shouldn't post a problem:
* Additional 'defined' checks simply check for netbsd or solaris, neither of
which is applicable here

* elif BOOST_PP_INTERATION_DEPTH changes, made for gcc 4.4 compatibility. Since
boost is already working against gcc in Fedora, this change isn't needed
(correct me if I'm wrong) 

* whitespace changes in non_type.hpp, which I'm guessing shouldn't be there as
nothing else is different



Issues which might pose a problem:
* the vendorized boost is at version 1.35 while in Fedora 14 we are going to be
at 1.44. I believe this just about summarizes the issue Fedora has with
vendorized libs, and I'm not sure if the thread library between these two
versions are compatible.

* the condition_varaible and mutex destructors and the condition_variable::wait
method try to repeat the necessary pthread destruction code until it is
successful, as opposed to attempting it once and verifying the result with
BOOST_VERIFY. As of right now I'm not sure why it does this, it seems to me
that if the pthread destruction call fails once, it'll fail everytime, and if
this is necessary on Linux. It may not be, this change maybe only for solaris
or something; some additional clarification would be great. If it is required
this is going to be very hard if not impossible to remove as if assertions in
boost are enabled, BOOST_VERIFY will terminate a running program (if the
condition being verified is false) and there isn't much we can do about it.

* changes to the exception hierarchy and additional exception information has
been added to thread_exception, thread_resource_error, and thread_interrupted,
to add backtrace and system_error_code support. Unless I'm mistaken these are
purely informational only (for debugging) and thus this shouldn't pose an issue
(once again correct me if I'm wrong). The apache hooks may have to be modified
though to remove the TRACE_POINTs (or perhaps not, still needs more
exploration)

* the thread constructor and start_thread method take an optional stack size.
>From my current understanding this is platform specific, and since boost is
already working on Fedora Linux x86 and x86_64 as is, this is unneeded.



That about covers it, I am going to attempt to see if I can passenger working
against boost in Fedora, but might not be able to for the aforementioned
reasons. If anyone knows any fault in my analysis above, or some other reason
why I won't be able to, please correct me, so that I don't invest a ton of time
into this. Also if I am successful, it may come at the price of a heavily
modified passenger source, but we'll tackle that if/when we get to that point.


P.S. would creating a separate upstream project resolve this issue without any
of this? Obviously someone would have to maintain this, but would something
like a passenger-boost project work?

-- 
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.