Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Numeric values of signals are wrong (say +SIGUSR1) #6488

Closed
p6rt opened this issue Sep 1, 2017 · 9 comments
Closed

Numeric values of signals are wrong (say +SIGUSR1) #6488

p6rt opened this issue Sep 1, 2017 · 9 comments
Labels
severe A problem that is encountered frequently, or a problem that needs attention for other reasons

Comments

@p6rt
Copy link

p6rt commented Sep 1, 2017

Migrated from rt.perl.org#132012 (status was 'rejected')

Searchable as RT132012$

@p6rt
Copy link
Author

p6rt commented Sep 1, 2017

From @AlexDaniel

Code​:
say +SIGUSR1

Result​:
30

However, on my system SIGUSR1 is *not* 30 (it is 10). I guess rakudo should try harder to find proper values of the system it runs on.

See this doc issue​: Raku/doc#1474

@p6rt
Copy link
Author

p6rt commented Sep 1, 2017

From @AlexDaniel

We now have a note in the docs about this. When fixed, change the docs accordingly (*maybe* saying that versions before X are known to have a bug).

Raku/doc@39e3efc08d

See IRC discussion​: https://irclog.perlgeek.de/perl6/2017-09-01#i_15103501
On 2017-09-01 03​:33​:34, alex.jakimenko@​gmail.com wrote​:

Code​:
say +SIGUSR1

Result​:
30

However, on my system SIGUSR1 is *not* 30 (it is 10). I guess rakudo
should try harder to find proper values of the system it runs on.

See this doc issue​: Raku/doc#1474

@p6rt
Copy link
Author

p6rt commented Oct 14, 2017

From @AlexDaniel

There's something regression-ish about it.

Code​:
say $*KERNEL.signal​: SIGUSR1

¦79b8ab9d3f^​:

10

¦79b8ab9d3f​:
30

See (2017-06-02) rakudo/rakudo@79b8ab9

On 2017-09-01 15​:39​:42, alex.jakimenko@​gmail.com wrote​:

We now have a note in the docs about this. When fixed, change the docs
accordingly (*maybe* saying that versions before X are known to have a bug).

Raku/doc@39e3efc08d

See IRC discussion​: https://irclog.perlgeek.de/perl6/2017-09-01#i_15103501
On 2017-09-01 03​:33​:34, alex.jakimenko@​gmail.com wrote​:

Code​:
say +SIGUSR1

Result​:
30

However, on my system SIGUSR1 is *not* 30 (it is 10). I guess rakudo
should try harder to find proper values of the system it runs on.

See this doc issue​: Raku/doc#1474

@p6rt
Copy link
Author

p6rt commented Oct 14, 2017

From @zoffixznet

On Fri, 13 Oct 2017 23​:34​:51 -0700, alex.jakimenko@​gmail.com wrote​:

There's something regression-ish about it.

Code​:
say $*KERNEL.signal​: SIGUSR1

¦79b8ab9d3f^​:

10

¦79b8ab9d3f​:
30

See (2017-06-02)
rakudo/rakudo@79b8ab9

On 2017-09-01 15​:39​:42, alex.jakimenko@​gmail.com wrote​:

We now have a note in the docs about this. When fixed, change the
docs
accordingly (*maybe* saying that versions before X are known to have
a bug).

Raku/doc@39e3efc08d

See IRC discussion​: https://irclog.perlgeek.de/perl6/2017-09-
01#i_15103501
On 2017-09-01 03​:33​:34, alex.jakimenko@​gmail.com wrote​:

Code​:
say +SIGUSR1

Result​:
30

However, on my system SIGUSR1 is *not* 30 (it is 10). I guess
rakudo
should try harder to find proper values of the system it runs on.

See this doc issue​: Raku/doc#1474

Something fishy going on with the Signals enum. If that's fixed then the
regression you pointed out will be fixed as well, as the new method simply
uses enum's `.value` to get the signal number​:

  <Zoffix__> c​: 79b8ab9d3f^,79b8ab9d3f,HEAD say SIGUSR1.Numeric; say SIGUSR1.value; say $*KERNEL.signal​: SIGUSR1
  <committable6> Zoffix__, ¦79b8ab9d3f^​: «30␤30␤10» ¦79b8ab9,HEAD(cc6c055)​: «30␤30␤30»

@p6rt
Copy link
Author

p6rt commented Oct 14, 2017

The RT System itself - Status changed from 'new' to 'open'

@p6rt
Copy link
Author

p6rt commented Oct 14, 2017

From @AlexDaniel

Someone asked why this issue is ANNOYING, here's some clafirication.

Basically, most of the stuff said said in linked comment applies here as well​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=131003#txn-1496218

In other words, *some* signals have correct values and you don't notice the issue right away.  Also, there's practically no workaround, unless you start hard-coding the values. I guess hard-coding can be counted as a workaround, except that it won't work on all systems. And this issue is very likely to be noticed by anybody using SIGUSR1. I think that's enough to justify the tag.

FWIW, I've also made a note about this issue in the docs, to prevent people from wasting their time on a known issue​: https://docs.perl6.org/type/Supply#sub_signal

On 2017-09-01 03​:33​:34, alex.jakimenko@​gmail.com wrote​:

Code​:
say +SIGUSR1

Result​:
30

However, on my system SIGUSR1 is *not* 30 (it is 10). I guess rakudo
should try harder to find proper values of the system it runs on.

See this doc issue​: Raku/doc#1474

@p6rt
Copy link
Author

p6rt commented Oct 18, 2017

From @zoffixznet

On Sat, 14 Oct 2017 08​:29​:50 -0700, cpan@​zoffix.com wrote​:

Something fishy going on with the Signals enum. If that's fixed then
the
regression you pointed out will be fixed as well, as the new method
simply
uses enum's `.value` to get the signal number​:

<Zoffix__> c​: 79b8ab9d3f^,79b8ab9d3f,HEAD say SIGUSR1.Numeric; say
SIGUSR1.value; say $*KERNEL.signal​: SIGUSR1
<committable6> Zoffix__, ¦79b8ab9d3f^​: «30␤30␤10»
¦79b8ab9,HEAD(cc6c055)​: «30␤30␤30»

There's also a failing spectest on Windows that expects both of these to give same value (on and Linux, they do)​:

C​:\rakudo>perl6 -e "$*KERNEL.signal('SIGHUP').say"
3

C​:\rakudo>perl6 -e "$*KERNEL.signal(SIGHUP).say"
1

@p6rt
Copy link
Author

p6rt commented Mar 4, 2018

From @AlexDaniel

Further discussion on rakudo/rakudo#1588

On 2017-10-18 03​:46​:20, cpan@​zoffix.com wrote​:

On Sat, 14 Oct 2017 08​:29​:50 -0700, cpan@​zoffix.com wrote​:

Something fishy going on with the Signals enum. If that's fixed then
the
regression you pointed out will be fixed as well, as the new method
simply
uses enum's `.value` to get the signal number​:

<Zoffix__> c​: 79b8ab9d3f^,79b8ab9d3f,HEAD say SIGUSR1.Numeric; say
SIGUSR1.value; say $*KERNEL.signal​: SIGUSR1
<committable6> Zoffix__, ¦79b8ab9d3f^​: «30␤30␤10»
¦79b8ab9,HEAD(cc6c055)​: «30␤30␤30»

There's also a failing spectest on Windows that expects both of these
to give same value (on and Linux, they do)​:

C​:\rakudo>perl6 -e "$*KERNEL.signal('SIGHUP').say"
3

C​:\rakudo>perl6 -e "$*KERNEL.signal(SIGHUP).say"
1

@p6rt
Copy link
Author

p6rt commented Mar 4, 2018

@AlexDaniel - Status changed from 'open' to 'rejected'

@p6rt p6rt closed this as completed Mar 4, 2018
@p6rt p6rt added the severe A problem that is encountered frequently, or a problem that needs attention for other reasons label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
severe A problem that is encountered frequently, or a problem that needs attention for other reasons
Projects
None yet
Development

No branches or pull requests

1 participant