rcu NPTL fix for 1.3.34

  Hi,

attached patch should make the rcu code NPTL compatible. Without the patch 
using an RCU will fail (vdr hang during startup) on an NPTL enabled system.

I have only move over L. Nussels lirc NPTL fix to the rcu code.

Greetings

Andreas




   int n = 0;
  

Andreas Share wrote:
> Hi,
> 
> attached patch should make the rcu code NPTL compatible. Without the 
> patch using an RCU will fail (vdr hang during startup) on an NPTL 
> enabled system.
> 
> I have only move over L. Nussels lirc NPTL fix to the rcu code.
> 
> Greetings
> 
> Andreas

Have you actually tested this?
I wonder if simply removing all lock calls would work,
because there _is_ a thread and a foreground function that
both want to transfer data...

Klaus

> --- rcu.c.org 2005-10-21 23:29:58.000000000 +0200
> +++ rcu.c 2005-10-21 23:29:36.000000000 +0200
> @@ -53,7 +53,11 @@
> 
> cRcuRemote::~cRcuRemote()
> {
> +  int fh = f;
> +  f = -1;
>   Cancel();
> +  if (fh >= 0)
> +     close(fh);
> }
> 
> bool cRcuRemote::Ready(void)
> @@ -100,7 +104,6 @@
> 
>   while (Running() && f >= 0) {
> 
> -        LOCK_THREAD;
> 
>         if (ReceiveByte(REPEATLIMIT) == 'X') {
>            for (int i = 0; i < 6; i++) {
> @@ -192,7 +195,6 @@
> 
> bool cRcuRemote::SendByte(unsigned char c)
> {
> -  LOCK_THREAD;
> 
>   for (int retry = 5; retry--;) {
>       if (SendByteHandshake(c))
> @@ -225,7 +227,6 @@
> 
> bool cRcuRemote::Number(int n, bool Hex)
> {
> -  LOCK_THREAD;
> 
>   if (!Hex) {
>      char buf[8];
> @@ -248,7 +249,6 @@
> 
> bool cRcuRemote::String(char *s)
> {
> -  LOCK_THREAD;
> 
>   const char *chars = mode == modeH ? "0123456789ABCDEF" : 
> "0123456789-EHLP ";
>   int n = 0;
  

----- Original Message ----- 
From: "Klaus Schmidinger" <Klaus.Schmidinger@cadsoft.de>
To: <vdr@linuxtv.org>
Sent: Friday, November 04, 2005 4:40 PM
Subject: Re: [vdr] [PATCH] rcu NPTL fix for 1.3.34


> Andreas Share wrote:
>> Hi,
>>
>> attached patch should make the rcu code NPTL compatible. Without the 
>> patch using an RCU will fail (vdr hang during startup) on an NPTL enabled 
>> system.
>>
>> I have only move over L. Nussels lirc NPTL fix to the rcu code.
>>
>> Greetings
>>
>> Andreas
>
> Have you actually tested this?
> I wonder if simply removing all lock calls would work,
> because there _is_ a thread and a foreground function that
> both want to transfer data...
>
> Klaus

Yes, i have tested the patch on my system. With the lock´s the rcu-code 
block vdr completely during startup with NPTL enabled libraries, especialy 
this ones in /lib/tls. LD_ASSUME_KERNEL doesn´t work for this problem, only 
moving the tls-folder away from /lib (and do a ldconfig afters this) have 
let the rcu work again on my suse 9.1.

Removing the lock in the main loop only will resolve this, but IR learning 
will fail, so i have removed the other locks also.

With the patch vdr/rcu (learning included) works without any sideeffect in 
daily use since 21.10. on my system (internal IR-Header, DBox IR Codes).

Greetings

Andreas Share
  

Andreas Share wrote:
> 
>> Andreas Share wrote:
>>
>>> Hi,
>>>
>>> attached patch should make the rcu code NPTL compatible. Without the 
>>> patch using an RCU will fail (vdr hang during startup) on an NPTL 
>>> enabled system.
>>>
>>> I have only move over L. Nussels lirc NPTL fix to the rcu code.
>>>
>>> Greetings
>>>
>>> Andreas
>>
>>
>> Have you actually tested this?
>> I wonder if simply removing all lock calls would work,
>> because there _is_ a thread and a foreground function that
>> both want to transfer data...
>>
>> Klaus
> 
> 
> Yes, i have tested the patch on my system. With the lock´s the rcu-code 
> block vdr completely during startup with NPTL enabled libraries, 
> especialy this ones in /lib/tls. LD_ASSUME_KERNEL doesn´t work for this 
> problem, only moving the tls-folder away from /lib (and do a ldconfig 
> afters this) have let the rcu work again on my suse 9.1.
> 
> Removing the lock in the main loop only will resolve this, but IR 
> learning will fail, so i have removed the other locks also.
> 
> With the patch vdr/rcu (learning included) works without any sideeffect 
> in daily use since 21.10. on my system (internal IR-Header, DBox IR Codes).
> 
> Greetings
> 
> Andreas Share

Well, I don't have a good feeling simply throwing out the
locks here just because NPTL can't handle them.

I guess this will have to wait then until I use NPTL myself,
although I don't see this happening any time soon... ;-)

Unless, of course, you can come up with a solution that
still does some locking and runs with NPTL. The file handle
_is_ accessed from both the foreground and the background thread,
so this just can't work reliably without locking.

Klaus
  

Klaus Schmidinger wrote:
> [...]
> Well, I don't have a good feeling simply throwing out the
> locks here just because NPTL can't handle them.

NPTL is fine. The way vdr used and maybe still uses locks at some
places was/is wrong (stuff like sleeping while locked). LinuxThreads
support has been removed from glibc btw. LD_ASSUME_KERNEL=... will
no longer work as workaround in the future.

cu
Ludwig
  

Ludwig Nussel wrote:
> Klaus Schmidinger wrote:
> 
>>[...]
>>Well, I don't have a good feeling simply throwing out the
>>locks here just because NPTL can't handle them.
> 
> 
> NPTL is fine. The way vdr used and maybe still uses locks at some
> places was/is wrong (stuff like sleeping while locked). LinuxThreads
> support has been removed from glibc btw. LD_ASSUME_KERNEL=... will
> no longer work as workaround in the future.

Well, can you point out exactly what VDR does wrong in rcu.c?
I don't think it is sleeping while locked...

Klaus
  

Klaus Schmidinger wrote:
> Ludwig Nussel wrote:
> >Klaus Schmidinger wrote:
> >
> >>[...]
> >>Well, I don't have a good feeling simply throwing out the
> >>locks here just because NPTL can't handle them.
> >
> >
> >NPTL is fine. The way vdr used and maybe still uses locks at some
> >places was/is wrong (stuff like sleeping while locked). LinuxThreads
> >support has been removed from glibc btw. LD_ASSUME_KERNEL=... will
> >no longer work as workaround in the future.
> 
> Well, can you point out exactly what VDR does wrong in rcu.c?
> I don't think it is sleeping while locked...

I didn't look at that specific code.

cu
Ludwig
  

> Andreas Share wrote:
>>
>>> Andreas Share wrote:
>>>
>>>> Hi,
>>>>
>>>> attached patch should make the rcu code NPTL compatible. Without the 
>>>> patch using an RCU will fail (vdr hang during startup) on an NPTL 
>>>> enabled system.
>>>>
>>>> I have only move over L. Nussels lirc NPTL fix to the rcu code.
>>>>
>>>> Greetings
>>>>
>>>> Andreas
>>>
>>>
>>> Have you actually tested this?
>>> I wonder if simply removing all lock calls would work,
>>> because there _is_ a thread and a foreground function that
>>> both want to transfer data...
>>>
>>> Klaus
>>
>>
>> Yes, i have tested the patch on my system. With the lock´s the rcu-code 
>> block vdr completely during startup with NPTL enabled libraries, 
>> especialy this ones in /lib/tls. LD_ASSUME_KERNEL doesn´t work for this 
>> problem, only moving the tls-folder away from /lib (and do a ldconfig 
>> afters this) have let the rcu work again on my suse 9.1.
>>
>> Removing the lock in the main loop only will resolve this, but IR 
>> learning will fail, so i have removed the other locks also.
>>
>> With the patch vdr/rcu (learning included) works without any sideeffect 
>> in daily use since 21.10. on my system (internal IR-Header, DBox IR 
>> Codes).
>>
>> Greetings
>>
>> Andreas Share
>
> Well, I don't have a good feeling simply throwing out the
> locks here just because NPTL can't handle them.
>
> I guess this will have to wait then until I use NPTL myself,
> although I don't see this happening any time soon... ;-)
>
> Unless, of course, you can come up with a solution that
> still does some locking and runs with NPTL. The file handle
> _is_ accessed from both the foreground and the background thread,
> so this just can't work reliably without locking.
>
> Klaus

Hi,

no problem for me, and because i think most other user uses lirc or the 
remote plugin to control vdr it is only a minor problem. So i still use rcu 
without the locks and wait until you use a NPTL enabled linux;)


Greetings
Andreas