As a follow-up, RHEL 3 did include the NPTL backport as per:
http://www.redhat.com/docs/manuals/enterprise/RHEL-3-Manual/release-notes/as-x86/
RHEL 2 did not, it was first introduced in RHEL 3.
RHEL AS 2.1 is still supported by Red Hat until May 31, 2009:
http://www.redhat.com/security/updates/errata/
I believe that will the the longest standing supported Linux
distro out there without NPTL since they 'support' it for 7 years.
When you said breaking compatibility with 2.4, you meant
NPTL vs LinuxThreads, right? Or am I totally going off on a
tangent.
That said, personally (selfishly?), my company does not support
RHEL2 anyhow so if it is just a matter of requiring NPTL and not
LinuxThreads (instead of as stated 2.4 vs 2.6 kernels), I'm
fine with that. (For those wondering, we don't support RHEL2
because it uses glibc 2.2, and we only support glibc 2.3.2
or higher).
Realistically though, you should probably wait until after
May 31, 2009 to do the cleanups.
When the cleanups are performed, you should definitely have a
runtime check to see if the system is running on NPTL or not
as someone could have defined LD_ASSUME_KERNEL=2.4.1 on an
NPTL-capable system to force it to use LinuxThreads (I think
a lot of Oracle install docs recommend setting that flag, so
if someone set it globally, well, that wouldn't be good).
Pretty sure RHEL5 was the first release to remove LinuxThreads
support all-together, RHEL3/4 allowed the LD_ASSUME_KERNEL trick.
As far as the run-time check, the only thing I can think of to
do is to spawn a thread that calls getpid() and return it
so pthread_join() can fetch it. If it matches the parent, it's
running NPTL, otherwise, LinuxThreads and some failure should
occur. Though getconf/sysconf(3) might be able to determine it
as well, but I'm not sure.
-Brad
Brad House wrote:
> I'm pretty sure both RHEL 2 & 3 both use 2.4 kernels and are
> still actively supported by RedHat if that sways your decision.
> I know I have clients that are on RHEL3 still so I'd prefer this
> change not to be made if there will be negative impact. We do
> share connections across threads, but not during a transaction,
> we just use a 'connection pool' and it grabs an inactive connection.
>
> That said, I'm pretty sure RHEL backported NPTL to 2.4, so it
> may not be relevant but I don't have the info on that currently,
> I can look that up.
>
> Thanks.
> -Brad
>
> D. Richard Hipp wrote:
>> Many systems built on the linux 2.4 kernels contain a bug in their
>> thread implementation: A posix advisory lock created by thread A
>> could not be overridden or modified by thread B. In essence, linux
>> was treating different threads within the same process as if they were
>> different processes. Long-time users of SQLite may recall that we
>> used to publish the restriction that SQLite database connections
>> created in one thread could not be used in a different thread. That
>> restriction was entirely a result of the afore mentioned bug in linux
>> 2.4.
>>
>> The unix drivers for SQLite contain a pile of ugly code to work around
>> this bug. I would very much like to delete that code for SQLite
>> version 3.6.7, due out in December. My question: would this cause
>> anyone any serious hardship?
>>
>> My impression is that everybody who runs linux upgraded to a version
>> 2.6 kernel at least two years ago. And even for those rare people who
>> have not, SQLite will still continue to work correctly provided that:
>>
>> (1) you do not attempt to move database connections across threads.
>> (2) you do not open connections to the same database file in two
>> different threads of the same process.
>>
>> So my questions is this, really: Is there anybody who runs SQLite on
>> a linux 2.4 kernel who either moves database connections across
>> threads or who opens multiple connections to the same database file in
>> separate threads of the same process?
>>
>> I am hoping that the answer to the previous question is "no" because I
>> really do want to simplify the SQLite unix drivers by deleting the
>> code that implements the linux thread/posix-lock bug work-around.
>>
>>
>> D. Richard Hipp
>> [EMAIL PROTECTED]
>>
>>
>>
>> ___
>> sqlite-users mailing list
>> sqlite-users@sqlite.org
>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
