[9fans] Different results for the same rc script when using listen1

[9fans] Different results for the same rc script when using listen1

[Maurício CA]

Hi, all,

This seems like black magic to me.  I've wrote this small example to
try to understand a problem with a bigger script.

    #!/usr/bin/env rc
    if (test 1 -ne 1) {
        echo I am insane.
    }
    if not {
        echo I am not insane.
    }

Obviously, when I run it, I get:

    I am not insane.

However, using (where 'listen_test.rc' is the name I gave this
script):

    listen1 'tcp!localhost!8080' ./listen_test.rc

and

    echo Hi | dial -e 'tcp!localhost!8080'

what I get is:

    I am insane.

How can running a script throw 'listen1' can get 'rc' to fail an 'if'
test?!?!

Thanks for your help,

Maurício

Re: [9fans] Different results for the same rc script when using listen1

[andrey mirtchovski]

I am unable to reproduce your result on OSX (p9p at tip):

$ echo Hi | dial -e 'tcp!localhost!8080'
I am not insane.
$

are you sure your listen1 isn't running an older version of the script?

Re: [9fans] Different results for the same rc script when using listen1

[Maurício CA]

> I am unable to reproduce your result on OSX (p9p at tip):
>
> $ echo Hi | dial -e 'tcp!localhost!8080'
> I am not insane.
> $
>
> are you sure your listen1 isn't running an older version of the script?
>

Yes, I am.  It's easy to check that by, say, changing a few letters in
the printed messages and observing the result.  Also, this simple
example was created to reproduce a problem I had with another one.

I'm using plan9 from user space, in Linux, using Arch linux
distribution.

Best,

Maurício

Re: [9fans] Different results for the same rc script when using listen1

[smiley]

Maurício CA <mauricio.antunes@gmail.com> writes:

> However, using (where 'listen_test.rc' is the name I gave this
> script):
>
>     listen1 'tcp!localhost!8080' ./listen_test.rc
>
> and
>
>     echo Hi | dial -e 'tcp!localhost!8080'
>
> what I get is:
>
>     I am insane.
>
> How can running a script throw 'listen1' can get 'rc' to fail an 'if'
> test?!?!

This looks like you're using p9p.  Have you checked your PATH?  It might
not be finding an executable, or finding the wrong version of an
executable.

-- 
+---------------------------------------------------------------+
|E-Mail: smiley@zenzebra.mv.com             PGP key ID: BC549F8B|
|Fingerprint: 9329 DB4A 30F5 6EDA D2BA  3489 DAB7 555A BC54 9F8B|
+---------------------------------------------------------------+

Re: [9fans] Different results for the same rc script when using listen1

[Maurício CA]

>> How can running a script throw 'listen1' can get 'rc' to fail an
>> 'if' test?!?!

> This looks like you're using p9p.  Have you checked your PATH?
> It might not be finding an executable, or finding the wrong version
> of an executable.

Sure. Take, for instance, this script uniquely named 'tester.rc':

   #!/usr/bin/env rc
   echo -n I am the real tester:
   ~ $1 $2

I can change 'listen_test.rc' to use it:

   #!/usr/bin/env rc
   for (i in `{seq 1 5}){
       if (./tester.rc $i 3) {
           echo ' ' $i equals 3
       }
       if not echo ' ' $i is different from 3
   }

Now I get:

   $./listen_test.rc
   I am the real tester:  1 is different from 3
   I am the real tester:  2 is different from 3
   I am the real tester:  3 equals 3
   I am the real tester:  4 is different from 3
   I am the real tester:  5 is different from 3

But:

   $listen1 'tcp!localhost!8080' ./listen_test.rc &
   $dial -e 'tcp!localhost!8080'
   I am the real tester:  1 equals 3
   I am the real tester:  2 equals 3
   I am the real tester:  3 equals 3
   I am the real tester:  4 equals 3
   I am the real tester:  5 equals 3


Thanks,

Maurício

Re: [9fans] Different results for the same rc script when using listen1

[Bakul Shah]

On Sun, 24 Apr 2011 17:05:43 -0000 =?UTF-8?Q?Maur=C3=ADcio?= CA <mauricio.antunes@gmail.com>  wrote:
> >> How can running a script throw 'listen1' can get 'rc' to fail an
> >> 'if' test?!?!
>
> > This looks like you're using p9p.  Have you checked your PATH?
> > It might not be finding an executable, or finding the wrong version
> > of an executable.
>
> Sure. Take, for instance, this script uniquely named 'tester.rc':
>
>    #!/usr/bin/env rc
>    echo -n I am the real tester:
>    ~ $1 $2
>
> I can change 'listen_test.rc' to use it:
>
>    #!/usr/bin/env rc
>    for (i in `{seq 1 5}){
>        if (./tester.rc $i 3) {
>            echo ' ' $i equals 3
>        }
>        if not echo ' ' $i is different from 3
>    }
>    $listen1 'tcp!localhost!8080' ./listen_test.rc &
>    $dial -e 'tcp!localhost!8080'

Doesn't fail here.

Make sure you are running $PLAN9/bin/rc. If so, rebuild all
(to start from a clean slate) and rerun your test

cd $PLAN9
# may be even do: hg pull -u
./INSTALL

Re: [9fans] Different results for the same rc script when using listen1

[Maurício CA]

> Doesn't fail here.
>
> Make sure you are running $PLAN9/bin/rc. If so, rebuild all (to start
> from a clean slate) and rerun your test

Uninstalled distribution package for plan9 and got .tgz at:

   http://swtch.com/plan9port/plan9port.tgz

MD5 checksum matched. Unpacked to /usr/local, executed ./INSTALL and
added recommended variables to the system profile.

   $ echo $PATH ----- $PLAN9 | tr ': ' '\n\n'
   /usr/local/bin
   /usr/bin
   /bin
   /usr/local/sbin
   /usr/sbin
   /sbin
   /usr/bin/core_perl
   /usr/local/plan9/bin
   -----
   /usr/local/plan9

Changed the test script, now named test.rc, to:

   #!/usr/local/plan9/bin/9 rc
   echo first at path: $path(1)
   for (i in `{seq 1 5}){
       if (test $i -eq 3) {
           echo $i equals 3
       }
       if not echo $i is different from 3
   }

Running /home/mauricio/test.rc:

   first at path: /usr/local/plan9/bin
   1 is different from 3
   2 is different from 3
   3 equals 3
   4 is different from 3
   5 is different from 3

Now with listen1 and dial:

   $ /usr/local/plan9/bin/9 listen1 'tcp!localhost!8080' /home/mauricio/test.rc &
   $ /usr/local/plan9/bin/9 dial 'tcp!localhost!8080'
   first at path: /usr/local/plan9/bin
   1 equals 3
   2 equals 3
   3 equals 3
   4 equals 3
   5 equals 3

My platform:

   $ uname -a | fmt
   Linux dumbo 2.6.38-ARCH #1 SMP PREEMPT Sun Apr 17 15:18:58 CEST 2011
   x86_64 Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz GenuineIntel GNU/Linux

This is really weird. I don't even know what could I check. 'listen1'
source code is pretty clean, and it calls command and args with a simple
'exec' call. The only thing that was also unusual is that the 'net'
variable, which is supposed to be set to a directory, is always blank,
but the line with 'putenv' and 'net' in 'listen1.c' is commented out,
so this is to be expected.

Thanks,

Maurício

Re: [9fans] Different results for the same rc script when using listen1

[Anthony Martin]

> This is really weird. I don't even know what could I check. 'listen1'
> source code is pretty clean, and it calls command and args with a simple
> 'exec' call. The only thing that was also unusual is that the 'net'
> variable, which is supposed to be set to a directory, is always blank,
> but the line with 'putenv' and 'net' in 'listen1.c' is commented out,
> so this is to be expected.

It fails on my Linux machine also.  It's because an rfork with
RFNOWAIT sets up a child proc that will ignore SIGCHLD.  If the
program that is executed (in this case rc) calls fork or exec
all SIGCHLD signals will be ignored, see signal(7).

Ultimately, this causes rc to set status='' for every process
it forks.  That's why all those tests are returning true.

The solution is probably just reenabling the SIGCHLD handler
at /usr/local/plan9/src/lib9/rfork.c:96 after the second fork.

  Anthony

Re: [9fans] Different results for the same rc script when using listen1

[andrey mirtchovski]

>   #!/usr/local/plan9/bin/9 rc
>   echo first at path: $path(1)
>   for (i in `{seq 1 5}){
>       if (test $i -eq 3) {
>           echo $i equals 3
>       }
>       if not echo $i is different from 3
>   }

NB: in general, you don't need 'test'. use "if (~ $i 3) {}".

that said, now I'm convinced there's a bug somewhere. I got your code
to fail under the condition that rc is started via the '9' environment
(9 rc). the type of 'test' binary doesn't matter -- both /bin/test and
$PLAN9/bin/test break under '9', but don't break without it. the '9'
script is pretty simple, but there appear do be some side-effects
(probably due to \r being transmitted over the network?). here's the
simplest version of your script:

$ cat t.rc
#!/usr/bin/env rc
exec rc
$

dial and test:

$ dial -e 'tcp!localhost!8080'
######## no breakage
/bin/test 1 -eq 2 ; echo $status
1
/bin/test 1 -eq 1; echo $status

/Users/andrey/plan9/bin/test 1 -eq 2; echo $status
1
/Users/andrey/plan9/bin/test 1 -eq 1; echo $status

######## now see it break
9 rc
/bin/test 1 -eq 2 ; echo $status

/bin/test 1 -eq 1; echo $status

/Users/andrey/plan9/bin/test 1 -eq 2; echo $status

/Users/andrey/plan9/bin/test 1 -eq 1; echo $status

ls | wc > /dev/null; echo $status
|
ls | wc > /dev/null; echo $status
|||
ls | wc > /dev/null; echo $status
|||||||
ls | wc > /dev/null; echo $status
|||||||||||||||
ls | wc > /dev/null; echo $status
|||||||||||||||||||||||||||||||

#####back to non-breaking rc:
exit
echo $status

ls | wc > /dev/null; echo $status
|
ls | wc > /dev/null; echo $status
|
ls | wc > /dev/null; echo $status
|
ls | wc > /dev/null; echo $status
|
ls | wc > /dev/null; echo $status
|

Re: [9fans] Different results for the same rc script when using listen1

[Iruatã Souza]

On Sun, Apr 24, 2011 at 11:03 PM, andrey mirtchovski
<mirtchovski@gmail.com> wrote:
>>   #!/usr/local/plan9/bin/9 rc
>>   echo first at path: $path(1)
>>   for (i in `{seq 1 5}){
>>       if (test $i -eq 3) {
>>           echo $i equals 3
>>       }
>>       if not echo $i is different from 3
>>   }
>
> NB: in general, you don't need 'test'. use "if (~ $i 3) {}".
>
> that said, now I'm convinced there's a bug somewhere. I got your code
> to fail under the condition that rc is started via the '9' environment
> (9 rc). the type of 'test' binary doesn't matter -- both /bin/test and
> $PLAN9/bin/test break under '9', but don't break without it. the '9'
> script is pretty simple, but there appear do be some side-effects
> (probably due to \r being transmitted over the network?). here's the
> simplest version of your script:
>
> $ cat t.rc
> #!/usr/bin/env rc
> exec rc
> $
>
> dial and test:
>
> $ dial -e 'tcp!localhost!8080'
> ######## no breakage
> /bin/test 1 -eq 2 ; echo $status
> 1
> /bin/test 1 -eq 1; echo $status
>
> /Users/andrey/plan9/bin/test 1 -eq 2; echo $status
> 1
> /Users/andrey/plan9/bin/test 1 -eq 1; echo $status
>
> ######## now see it break
> 9 rc
> /bin/test 1 -eq 2 ; echo $status
>
> /bin/test 1 -eq 1; echo $status
>
> /Users/andrey/plan9/bin/test 1 -eq 2; echo $status
>
> /Users/andrey/plan9/bin/test 1 -eq 1; echo $status
>
> ls | wc > /dev/null; echo $status
> |
> ls | wc > /dev/null; echo $status
> |||
> ls | wc > /dev/null; echo $status
> |||||||
> ls | wc > /dev/null; echo $status
> |||||||||||||||
> ls | wc > /dev/null; echo $status
> |||||||||||||||||||||||||||||||
>
> #####back to non-breaking rc:
> exit
> echo $status
>
> ls | wc > /dev/null; echo $status
> |
> ls | wc > /dev/null; echo $status
> |
> ls | wc > /dev/null; echo $status
> |
> ls | wc > /dev/null; echo $status
> |
> ls | wc > /dev/null; echo $status
> |
>
>

I'm seeing this without the 9. It is a Ubuntu 10.04.2 LTS,

$ uname -a
Linux goitaca 2.6.32-28-generic #55-Ubuntu SMP Mon Jan 10 23:42:43 UTC
2011 x86_64 GNU/Linux

Re: [9fans] Different results for the same rc script when using listen1

[andrey mirtchovski]

same for me on linux too (previous tests were on osx). i'm sure
anthony's analysis is the correct one.

Re: [9fans] Different results for the same rc script when using listen1

[Maurício CA]

> It fails on my Linux machine also.  It's because an rfork with RFNOWAIT
> sets up a child proc that will ignore SIGCHLD.  If the program that
> is executed (in this case rc) calls fork or exec all SIGCHLD signals
> will be ignored, see signal(7).
>
> Ultimately, this causes rc to set status='' for every process it forks.
> That's why all those tests are returning true.

Instead of assuming status='' for every process, rc seems to be just
ignoring process status and keeping the $status value it already had. See
this example, exactly like what I used before, but with a pattern test
that set status to 'no match':

   #!/usr/local/plan9/bin/9 rc
   ~ 1 2
   for (i in `{seq 1 5}){
       if (test $i -eq 3) {
           echo $i equals 3
       }
       if not echo $i is different from 3
   }

Now, instead of true for every step, we have false:

   $ dial 'tcp!localhost!8080'
   1 is different from 3
   2 is different from 3
   3 is different from 3
   4 is different from 3
   5 is different from 3

Thanks,

Maurício

Re: [9fans] Different results for the same rc script when using listen1

[erik quanstrom]

On Sun Apr 24 22:01:41 EDT 2011, ality@pbrane.org wrote:
> > This is really weird. I don't even know what could I check. 'listen1'
> > source code is pretty clean, and it calls command and args with a simple
> > 'exec' call. The only thing that was also unusual is that the 'net'
> > variable, which is supposed to be set to a directory, is always blank,
> > but the line with 'putenv' and 'net' in 'listen1.c' is commented out,
> > so this is to be expected.
>
> It fails on my Linux machine also.  It's because an rfork with
> RFNOWAIT sets up a child proc that will ignore SIGCHLD.  If the
> program that is executed (in this case rc) calls fork or exec
> all SIGCHLD signals will be ignored, see signal(7).
>
> Ultimately, this causes rc to set status='' for every process
> it forks.  That's why all those tests are returning true.
>
> The solution is probably just reenabling the SIGCHLD handler
> at /usr/local/plan9/src/lib9/rfork.c:96 after the second fork.

hmm.  is that right?  it's wait3/wait4 that's failing.  it shouldn't
be necesary to catch SIGCHLD for wait to work.  but maybe
it is

here's some awful debugging output:

pid 20658 cycle 00627820 46 Xsimple (echo 2 eq 3) (3)
echo 2 eq 3
pid=20658	addwaitpid 20661
pid=20658	20659 20660 20661
waitfor 20661
pid=20661	clearwaitpids
2 eq 3
await returns -1		errstr=No child processes
	nothing to wait for ??

- erik

Re: [9fans] Different results for the same rc script when using listen1

[erik quanstrom]

; hg diff rfork.c
> hmm.  is that right?  it's wait3/wait4 that's failing.  it shouldn't
> be necesary to catch SIGCHLD for wait to work.  but maybe
> it is

i take it back.  i'd forgotten how quirky unix is these days.
here's the solution.  not rc's fault.  recompile lib9 and listen1:

diff -r 5caa04977471 src/lib9/rfork.c
--- a/src/lib9/rfork.c	Sun Dec 27 09:22:43 2009 -0800
+++ b/src/lib9/rfork.c	Sun Apr 24 23:33:52 2011 -0400
@@ -18,7 +18,9 @@
 	int n;
 	char buf[128], *q;
 	extern char **environ;
+	void *oldchild;

+	oldchild = nil;
 	if((flags&(RFPROC|RFFDG|RFMEM)) == (RFPROC|RFFDG)){
 		/* check other flags before we commit */
 		flags &= ~(RFPROC|RFFDG|RFENVG);
@@ -34,7 +36,7 @@
 			 * NOWAIT once, they're not likely to want child notes
 			 * after that.
 			 */
-			signal(SIGCHLD, nop);
+			oldchild = signal(SIGCHLD, nop);
 			if(pipe(p) < 0)
 				return -1;
 		}
@@ -81,7 +83,10 @@
 				 * Child - fork a new child whose wait message can't
 				 * get back to the parent because we're going to exit!
 				 */
-				signal(SIGCHLD, SIG_IGN);
+				if(oldchild == nil)
+					oldchild = signal(SIGCHLD, SIG_IGN);
+				else
+					signal(SIGCHLD, SIG_IGN);
 				close(p[0]);
 				pid = fork();
 				if(pid){
@@ -95,6 +100,8 @@
 				}else{
 					/* Child child - close pipe. */
 					close(p[1]);
+					if(oldchild)
+						signal(SIGCHLD, oldchild);
 				}
 			}
 		}


- erik

Re: [9fans] Different results for the same rc script when using listen1

[Bakul Shah]

> i take it back.  i'd forgotten how quirky unix is these days.
> here's the solution.  not rc's fault.  recompile lib9 and listen1:

*Linux*, not unix.

Re: [9fans] Different results for the same rc script when using listen1

[erik quanstrom]

On Sun Apr 24 23:59:37 EDT 2011, bakul@bitblocks.com wrote:
> > i take it back.  i'd forgotten how quirky unix is these days.  >
> here's the solution.  not rc's fault.  recompile lib9 and listen1:
>
> *Linux*, not unix.

this meme is ancient
time to give it die today
linux is unix

- erik

Re: [9fans] Different results for the same rc script when using listen1

[Lyndon Nerenberg]

> this meme is ancient
> time to give it die today
> linux is unix

Not while the BSD line lives.

Re: [9fans] Different results for the same rc script when using listen1

[Bakul Shah]

On Apr 24, 2011, at 9:39 PM, erik quanstrom wrote:

> On Sun Apr 24 23:59:37 EDT 2011, bakul@bitblocks.com wrote:
>>> i take it back.  i'd forgotten how quirky unix is these days.  >
>> here's the solution.  not rc's fault.  recompile lib9 and listen1:
>> 
>> *Linux*, not unix.
> 
> this meme is ancient
> time to give it die today
> linux is unix


Actually, no. At least *BSD has evolved from Unix(TM) over time. Not a from scratch implementation.

If you had said

	this `Unix' is ancient
	time to give it die today
	Linux is it

that'd be more likely to be accurate. There are plenty of people who have heard of Linux and not Unix.

Re: [9fans] Different results for the same rc script when using listen1

[Robert Ransom]

[-- Attachment #1: Type: text/plain, Size: 862 bytes --]

On Sun, 24 Apr 2011 22:53:19 -0700
Bakul Shah <bakul@bitblocks.com> wrote:

> 
> On Apr 24, 2011, at 9:39 PM, erik quanstrom wrote:
> 
> > On Sun Apr 24 23:59:37 EDT 2011, bakul@bitblocks.com wrote:
> >>> i take it back.  i'd forgotten how quirky unix is these days.  >
> >> here's the solution.  not rc's fault.  recompile lib9 and listen1:
> >> 
> >> *Linux*, not unix.
> > 
> > this meme is ancient
> > time to give it die today
> > linux is unix
> 
> 
> Actually, no. At least *BSD has evolved from Unix(TM) over time. Not a from scratch implementation.
> 
> If you had said
> 
> 	this `Unix' is ancient
> 	time to give it die today
> 	Linux is it
> 
> that'd be more likely to be accurate. There are plenty of people who have heard of Linux and not Unix.

count the syllables
six, then seven, then four more?
yours is no haiku

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 501 bytes --]

Re: [9fans] Different results for the same rc script when using listen1

[Maurício CA]

> here's the solution.  not rc's fault.  recompile lib9 and listen1:
>

Great. It solves the problem.

Since this is specific to plan9 unix port, is it necessary to post this
on plan9port-dev group so it can be inserted in the oficial code?

Also, your path should remove the funny comment just where your correction
was necessary:

   /*
    * BUG - should put the signal handler back after we
    * finish, but I just don't care.  If a program calls with
    * NOWAIT once, they're not likely to want child notes
    * after that.
    */

:)

Thanks a lot,
Maurício

Re: [9fans] Different results for the same rc script when using listen1

[erik quanstrom]

On Mon Apr 25 09:54:36 EDT 2011, mauricio.antunes@gmail.com wrote:
> > here's the solution.  not rc's fault.  recompile lib9 and listen1:
> >
>
> Great. It solves the problem.
>
> Since this is specific to plan9 unix port, is it necessary to post this
> on plan9port-dev group so it can be inserted in the oficial code?
>
> Also, your path should remove the funny comment just where your correction
> was necessary:
>
>    /*
>     * BUG - should put the signal handler back after we
>     * finish, but I just don't care.  If a program calls with
>     * NOWAIT once, they're not likely to want child notes
>     * after that.
>     */

go for it.

- erik

Re: [9fans] Different results for the same rc script when using listen1

[erik quanstrom]

> Actually, no. At least *BSD has evolved from Unix(TM) over time. Not a from scratch implementation.

bsd is like george washington's axe.  i bet you can find more
lines of code in common between us and a slime mould than
you can between any modern bsd and v7.  :-)

- erik

Re: [9fans] Different results for the same rc script when using listen1

[Bakul Shah]

On Apr 24, 2011, at 11:59 PM, Robert Ransom wrote:

> On Sun, 24 Apr 2011 22:53:19 -0700
> Bakul Shah <bakul@bitblocks.com> wrote:
> 
>> 
>> On Apr 24, 2011, at 9:39 PM, erik quanstrom wrote:
>> 
>>> On Sun Apr 24 23:59:37 EDT 2011, bakul@bitblocks.com wrote:
>>>>> i take it back.  i'd forgotten how quirky unix is these days.  >
>>>> here's the solution.  not rc's fault.  recompile lib9 and listen1:
>>>> 
>>>> *Linux*, not unix.
>>> 
>>> this meme is ancient
>>> time to give it die today
>>> linux is unix
>> 
>> 
>> Actually, no. At least *BSD has evolved from Unix(TM) over time. Not a from scratch implementation.
>> 
>> If you had said
>> 
>> 	this `Unix' is ancient
>> 	time to give it die today
>> 	Linux is it
>> 
>> that'd be more likely to be accurate. There are plenty of people who have heard of Linux and not Unix.
> 
> count the syllables
> six, then seven, then four more?
> yours is no haiku


this ancient unix
time to kill it dead and good
linux is it. Yuck!

Happy?

Re: [9fans] Different results for the same rc script when using listen1

[erik quanstrom]

> this ancient unix
> time to kill it dead and good
> linux is it. Yuck!
>
> Happy?

+1 rofl.

- erik

Re: [9fans] Different results for the same rc script when using listen1

[Skip Tavakkolian]

where's the "Like" button on this thing?

On Mon, Apr 25, 2011 at 7:56 AM, Bakul Shah <bakul@bitblocks.com> wrote:
>
>
>
> this ancient unix
> time to kill it dead and good
> linux is it. Yuck!
>
> Happy?
>

Re: [9fans] Different results for the same rc script when using listen1

[Joseph Stewart]

[-- Attachment #1: Type: text/plain, Size: 422 bytes --]

Yeah, I agree... too much FB makes me want a "like" button on my mail
client!

On Mon, Apr 25, 2011 at 12:17 PM, Skip Tavakkolian <
skip.tavakkolian@gmail.com> wrote:

> where's the "Like" button on this thing?
>
> On Mon, Apr 25, 2011 at 7:56 AM, Bakul Shah <bakul@bitblocks.com> wrote:
> >
> >
> >
> > this ancient unix
> > time to kill it dead and good
> > linux is it. Yuck!
> >
> > Happy?
> >
>
>

[-- Attachment #2: Type: text/html, Size: 822 bytes --]

Re: [9fans] Different results for the same rc script when using listen1

[smiley]

Skip Tavakkolian <skip.tavakkolian@gmail.com> writes:

> where's the "Like" button on this thing?

I think there's an fs for that.  ;)

--
+---------------------------------------------------------------+
|E-Mail: smiley@zenzebra.mv.com             PGP key ID: BC549F8B|
|Fingerprint: 9329 DB4A 30F5 6EDA D2BA  3489 DAB7 555A BC54 9F8B|
+---------------------------------------------------------------+

Re: [9fans] Different results for the same rc script when using listen1

[Lyndon Nerenberg]

> I think there's an fs for that.  ;)

"There's a file system for that."
 	-- new plan9 marketing slogan ;-)

Re: [9fans] Different results for the same rc script when using listen1

[erik quanstrom]

On Mon Apr 25 16:15:26 EDT 2011, smiley@zenzebra.mv.com wrote:
> Skip Tavakkolian <skip.tavakkolian@gmail.com> writes:
>
> > where's the "Like" button on this thing?
>
> I think there's an fs for that.  ;)

there's no reason upas/fs and its clients couldn't
support a like button, but it would be hard to make
work with everybody else, without resorting to nasty
html tricks.

- erik

Re: [9fans] Different results for the same rc script when using listen1

[dexen deVries]

Hi,


On Monday 25 of April 2011 05:36:17 erik quanstrom wrote:
> ; hg diff rfork.c
> 
> > hmm.  is that right?  it's wait3/wait4 that's failing.  it shouldn't
> > be necesary to catch SIGCHLD for wait to work.  but maybe
> > it is
> 
> i take it back.  i'd forgotten how quirky unix is these days.
> here's the solution.  not rc's fault.  recompile lib9 and listen1:
> 
> diff -r 5caa04977471 src/lib9/rfork.c
> (...)


back in 13/05/2009 00:57 i've submitted a different patch for that
(mail with subject ``[p9p] Bug in signal handling''). it seems simplier; any 
chances it gets the job done an easier way?

here again, with whitespace cleanup:

diff -r bde374c81d7e src/lib9/notify.c
--- a/src/lib9/notify.c Tue Jan 25 12:13:44 2011 +0100
+++ b/src/lib9/notify.c Tue Apr 26 11:01:25 2011 +0200
@@ -265,7 +265,8 @@
                 * Or maybe someone has already called notifyon/notifyoff.
                 * Leave it alone.
                 */
-               if(handler(sig->sig) != SIG_DFL)
+               if((handler(sig->sig) != SIG_DFL)
+                       && handler(sig->sig) != SIG_IGN)
                        continue;
                notifyseton(sig->sig, !(sig->flags&NoNotify));
        }



-- 
dexen deVries

[[[↓][→]]]

``In other news, STFU and hack.''
mahmud, in response to Erann Gat's ``How I lost my faith in Lisp''
http://news.ycombinator.com/item?id=2308816

Re: [9fans] Different results for the same rc script when using listen1

[erik quanstrom]

> > i take it back.  i'd forgotten how quirky unix is these days.
> > here's the solution.  not rc's fault.  recompile lib9 and listen1:
> >
> > diff -r 5caa04977471 src/lib9/rfork.c
> > (...)
>
>
> back in 13/05/2009 00:57 i've submitted a different patch for that
> (mail with subject ``[p9p] Bug in signal handling''). it seems simplier; any
> chances it gets the job done an easier way?
>
> here again, with whitespace cleanup:
>
> diff -r bde374c81d7e src/lib9/notify.c
> --- a/src/lib9/notify.c Tue Jan 25 12:13:44 2011 +0100
> +++ b/src/lib9/notify.c Tue Apr 26 11:01:25 2011 +0200
> @@ -265,7 +265,8 @@
>                  * Or maybe someone has already called notifyon/notifyoff.
>                  * Leave it alone.
>                  */
> -               if(handler(sig->sig) != SIG_DFL)
> +               if((handler(sig->sig) != SIG_DFL)
> +                       && handler(sig->sig) != SIG_IGN)
>                         continue;
>                 notifyseton(sig->sig, !(sig->flags&NoNotify));
>         }

that's not the same bug.  noteinit() isn't going to be called by
rc through Trapinit() again after the exec.

- erik

Re: [9fans] Different results for the same rc script when using listen1

[Maurício CA]

>>> here's the solution.  not rc's fault.  recompile lib9 and listen1:

>> Great. It solves the problem.  Since this is specific to plan9 unix
>> port, is it necessary to post this on plan9port-dev group so it can
>> be inserted in the oficial code?

> go for it.

Just to let you know, I opened an issue ticket regarding this:

  https://bitbucket.org/rsc/plan9port/issue/73/bug-in-src-lib9-rforkc-damages-listen1

Best,
Maurício