Bug#266507: NPTL (0.60) quirks with pthread_create (ignores attributes)
On Thu, 19 Aug 2004 13:44:05 +0900
GOTO Masanori <gotom@debian.or.jp> wrote:
> At Wed, 18 Aug 2004 04:51:59 +0200,
> Florian Schmidt wrote:
> > there's a problem with the libc6 package and a 2.6.x kernel. I have
> > attached two test programs to illustrate the problem
> > [test_thread_attr.cc and test_thread_post.cc; compile each with
> > -lpthread].
> >
> > The programs try to create a SCHED_FIFO thread. test_thread_attr
> > tries this by setting the attributes before creating the thread.
> > test_thread_post does this by using setschedparam explicitly after
> > thread creation.
> >
> > test_thread_attr fails silently. It reports no error ps -C
> > test_thread_attr -cmL shows there are no SCHED_FIFO threads created:
>
> AFAIK, one trial to fix this kind of problem is Robust Mutex. They're
> proposing kernel modification "fusyn", however I guess these
> modifications will go into 2.7.
Well, several members of the jack audio connection kit mailing list
[jackit-devel@lists.sf.net] have reported that using NPTL 0.61 fixes the
issue. I think i read on lkml that there are strong arguments
against robust mutexes. So basically i don't know if the underlying
kernel issues will ever be fixed, but silently ignoring the attributes
without producing an error is just nuts! Either succeed or fail with an
error. It took like 3 months to find out what the issue was with jackd
because pthread_create() just seemed to succeed while in reality it
didn't even try to behave posix conform.. Matters got complicated,
because seemingly NPTL 0.61 behaves ok again [and in this case jackd
only needed an explicit setinheritsched() call since the default
behaviour was changed from LinuxThreads to NPTL].
There's also an ugly hack which consists of using the LD_ASSUME_KERNEL
env var to make libc use LinuxThreads [for example
LD_ASSUME_KERNEL=2.4.22 jackd -R -d alsa -p 512]. But i'm quite sure
there are a few other side effects besides "correcting" the pthread
behaviour.
I don't know if recent linux 2.6.x versions are "fixed", but it seems
that NPTL devs think it's good enough that the pthread lib follows posix
again otherwise they wouldn't have made 0.61 "work" again..
But basically the debian libc6 breaks pretty much all programs trying to
change the scheduling policy of threads to RT [if they don't contain
workarounds like in the test_thread_post example code].
flo
Reply to: