Re: glibc 2.1.3pre1 with Linuxthreads 2.1.3pre2 made my applicationwork again

[Kaz Kylheku <kaz at ashi dot footprints dot net>]

On Sun, 30 Jan 2000, Kai Engert wrote:

> Ok, so people not using this mechanism shouldn't be required to update
> :-)

That is actually reasonable, so no smiley required. If your application is not
affected by an issue and its fix, I wouldn't recommend that you upgrade (for
the sake of getting just that fix.) The fixes are not without risk, and the
fixed library is only a pre-release version that hasn't been tested by a lot of
people. There are also other changes in it, like design changes to the
read-write lock code to make writer preference work while obeying Unix98.

> However, users of third party developed multithreaded software can't be
> sure whether they are affected.

That's right; so they should check with their developers. In the absence of
knowing whether a binary appliaction is affected or not, it is probably best
to try your luck with the upgrade (in this particular case, not necessarily as
a general principle!)

> I read the Oracle database servers are using LinuxThreads, too.
> I'm curious whether they experienced problems.

Again, I doubt that they pthread_create() and pthread_cancel() threads on the
fly. But they might be using pthread_cond_timedwait which would bite them.

I know that the MySQL people experienced stability problems related to
pthread_cond_timedwait.

> Do you think, as soon as glibc 2.1.3 is released, someone should make an
> announcement to comp.programming.threads, mentioning the fix and
> recommending to update?

I think it has already been debated enough in comp.programming.threads, but it
could be worthwhile nevertheless. Or perhaps the newsgroups
comp.os.linux.announce or c.o.l.development.{system,apps}.  Anyone doing
serious Linux development should keep up with mailing lists like libc-alpha,
and the kernel mailing lists, and watch the newsgroups. Developers who don't
pay attention to what is going on in the community are on their own.