Paavo Hartikainen wrote: > Johannes Stezenbach <js@xxxxxxxxxxx> writes: > > >>The patch below might help, gettid() returns the PID of the >>thread. (And since it's a syscall it is independent of NPTL >>vs. linuxthreads. Tested on 2.6 only, but the gettid man page says >>it's available in 2.4.20. gettid() is Linux specific.) > > > Before patch: > --- > Dec 3 05:27:30 sarabi vdr[22722]: tuner on device 1 thread started (pid=22722, tid=822543584) > Dec 3 05:27:32 sarabi vdr[22722]: tuner on device 2 thread started (pid=22722, tid=814154976) > --- > > After patch: > --- > Dec 5 04:31:46 sarabi vdr[27624]: tuner on device 1 thread started (pid=27624, tid=-1) > Dec 5 04:31:48 sarabi vdr[27624]: tuner on device 2 thread started (pid=27624, tid=-1) > --- > > After patch and "env LD_ASSUME_KERNEL=2.4.1": > --- > Dec 5 04:35:01 sarabi vdr[27641]: tuner on device 1 thread started (pid=27641, tid=-1) > Dec 5 04:35:03 sarabi vdr[27644]: tuner on device 2 thread started (pid=27644, tid=-1) > --- This would indicate that the gettid() call has failed (returned -1). What system is this happening on? I tested it here on a SUSE 8.2 (kernel 2.4.20) and SUSE 10.0 (kernel 2.6.13), and it worked fine on both of them. On the kernel 2.4.20 system it returned the same value as the getpid() call, and on the 2.6.13 system it returned pid values that were counted upwards from the main thread's pid. Klaus
