[vdr] VDR gets somehow stuck and consumes all CPU time
Klaus.Schmidinger at cadsoft.de
Sat Dec 10 18:05:17 CET 2005
Johannes Stezenbach wrote:
> Klaus Schmidinger wrote:
>>Johannes Stezenbach wrote:
>>>pthread_self() has to be used within programs using to identify
>>>the threads. gettid() is more a debugging aid as the return value
>>>of pthread_self() has no meaning outside the context of the running
>>>program. (Funny that glibc doesn't have a syscall wrapper for
>>>gettid(); dietlibc has.)
>>Thanks, this appears to work just fine.
>>I assume it's ok to use the SYS_gettid macro, as in
>>static inline pid_t gettid(void)
>> return syscall(SYS_gettid);
>>instead of the hardcoded 224.
> The man page actually suggests:
> #include <sys/types.h>
> #include <linux/unistd.h>
> (I just made a mistake and included <unistd.h> instead of <linux/unistd.h>
> so it didn't work when I initially tested it.)
Ok, I'll make it that way then.
Do you think we need a fallback solution, just in case the syscall fails?
Paavo Hartikainen's posting (12/05/05 03:57) would indicate that this
Maybe we should use pthread_self() in case gettid() returns -1, and
use pthread_t to store such values, because it's large enough to hold
pid_t as well as pthread_t.
Or should we make this system dependent (with #ifdef)?
So that non-Linux systems can provide a different solution.
More information about the vdr