[vdr] VDR gets somehow stuck and consumes all CPU time

[Klaus Schmidinger]

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
>>
>>
>>
>>#include <sys/syscall.h>
>>
>>static inline pid_t gettid(void)
>>{
>>  return syscall(SYS_gettid);
>>}
>>
>>
>>
>>instead of the hardcoded 224.
> 
> 
> The man page actually suggests:
> http://homepages.cwi.nl/~aeb/linux/man2html/man2/gettid.2.html
> 
> #include <sys/types.h>
> #include <linux/unistd.h>
> 
> _syscall0(pid_t,gettid)
> 
> (I just made a mistake and included <unistd.h> instead of <linux/unistd.h>
> so it didn't work when I initially tested it.)
> 
> Johannes

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
can happen.

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.

Klaus