Ville Skyttä wrote:
Hello Ville,
I'm making this a ML posting to allow others to comment on this, too. Hope that's ok with you.
Well, looking at <pthread.h> it does look like there actually should be a pointer to a 'struct sched_param'.
But then again it says:
The realtime scheduling policies SCHED_RR and SCHED_FIFO are available only to processes with superuser privileges.
which VDR usually isn't.
Since I assume that the line in question doesn't have any effect if a NULL pointer is given as 'param', maybe it's safe to drop it altogether?
Klaus
On Sun, 2006-05-28 at 18:15 +0200, Klaus Schmidinger wrote:
I'm making this a ML posting to allow others to comment on this, too. Hope that's ok with you.
Sure, thanks, I wasn't aware that it might be of interest to a wider audience.
Dunno, sorry.
Klaus Schmidinger wrote:
I'm not sure if there is any connection to this, but valgrind complains:
==6486== Syscall param write(buf) points to uninitialised byte(s) ==6486== at 0x1B93FA3B: write (in /usr/lib/debug/libpthread-0.10.so) ==6486== by 0x1B93BC6A: pthread_create@@GLIBC_2.1 (pthread.c:817) ==6486== by 0x8135CC9: cThread::Start() (thread.c:256) ==6486== by 0x8107B77: cRecordings::Update(bool) (recording.c:1043) ==6486== by 0x814208C: main (vdr.c:546) ==6486== Address 0x52BFE590 is on thread 1's stack
Unfortunately I couldn't figure out yet, what's going on there, so I just ignored it and added it to the suppression file. It might simply be a problem with valgrind.
Tobias
I demand that Tobias Grimm may or may not have written...
That'd be the third parameter of pthread_setschedparam. Something like __attribute__ ((nonnull (3))) attached to the declaration of pthread_setschedparam would do it; I don't see anything like that here, but perhaps there are some in glibc 2.4's <pthread.h>?
I'm not sure if there is any connection to this, but valgrind complains:
[snip]
Either that or it's a glibc bug.
-
Darren Salt -
Klaus Schmidinger -
Tobias Grimm -
Ville Skyttä