Rainer Zocholl wrote:
well, I'm running it *with* LD_ASSUME_KERNEL. Anyway, on mandrake, it shouldn't make a difference wrt thread local storage, the only difference should be the use of linuxthreads/pthreads.luca@ventoso.org(Luca Olivetti) 04.12.04 18:20Rainer Zocholl wrote:After replacing all obviously/known not thread save clib calls with their thread save counterparts osdteletext now runs! I would not waste any time to investigate which of those calls are the minimum or why the seg faults are caused in detail. There is no adavantage using non-thread save functions in a multithreaded environment. The overhead is neglectable.Interesting. I've asked google and it told me that the tls ("thread local storage") version of the library doesn't need the _r version of the functions, and that could explain why not everybody is seeing the problem. However, that doesn't explain why *I* was not seeing it, since I'm running vdr with LD_ASSUME_KERNEL=2.4.1:[vdr@vdr vdr]$ LD_ASSUME_KERNEL=2.4.1 ldd vdr linux-gate.so.1 => (0xffffe000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x4002c000) libpthread.so.0 => /lib/i686/libpthread.so.0 (0x4004b000) libdl.so.2 => /lib/libdl.so.2 (0x4009d000) libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x400a0000) libm.so.6 => /lib/i686/libm.so.6 (0x40160000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40183000) libc.so.6 => /lib/i686/libc.so.6 (0x4018c000) ^^^^ normal, non thread safe, version /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)Now i think i (maybe) know what's going on... with the recommandation to set LD_ASSUME_KERNEL=2.4.1! If you don't set it, you will get "thread local data", not just an reentrant "ctime".
You'll have to ask a glibc expert, but I don't think that's the way it's intended to work. It doesn't make sense, but then even C and C++ do not ;-)If you now define a mutex, that mutex will be thread local!(?) So the entire locking will not work as intended?
Attachment:
signature.asc
Description: OpenPGP digital signature