Discussion:
[perl #57920] Patch suggestion for Parrot Configure test of AIO
(too old to reply)
James Keenan via RT
2008-08-25 16:38:24 UTC
Permalink
On my computer (OpenSuse 11.0) the Parrot Configure.pl hangs forever
when
checking for platfom support for AIO.
It appears to be a neverending sleep(1) loop in the check.
In the patch I have added a countdown to make it exit after some time,
anyway.
Erik:

The patch looks reasonable to me and, at the very least, Does No Harm on
Linux. A couple of points/questions:

1. After you run 'perl Configure.pl' with this patch on your box, what
do you get for this:

grep -ni AIO lib/Parrot/Config/Generated.pm

2. Your patch inspired me to check for other instances of 'sleep' in
the Parrot configuration system. I couldn't find any, which is a Good
Thing, IMHO.

3. For future reference, submit bug reports to:
***@parrotcode.org. I recommend beginning Subject line with:
[BUG]. And I recommend submitting patches as email attachment ending in
: .txt (because that seems to render best in browsers, mail, news
interfaces).

All:

Can we get this patch tried out on a few more OSes?

Thank you very much.
kid51
Allison Randal
2008-08-25 20:14:47 UTC
Permalink
Post by James Keenan via RT
[BUG]. And I recommend submitting patches as email attachment ending in
: .txt (because that seems to render best in browsers, mail, news
interfaces).
Generally recommend attaching patches as files ending in .patch (as
documented in docs/submissions.pod) for the sanity of the patch
monsters. It makes patches immediately identifiable, versus large text
files of output from some debugging process.

Allison
James Keenan via RT
2008-08-25 20:51:33 UTC
Permalink
Post by Allison Randal
Generally recommend attaching patches as files ending in .patch (as
documented in docs/submissions.pod) for the sanity of the patch
monsters.
Well, since it's in the docs, I will withdraw the suggestion.

However, *I* am one of the patch monsters whose sanity you are concerned
with, and I have found that if the file ends in '.patch' I have to tell
my browser/mail client/newsreader what other program to open it with. I
don't have to do that if it ends in '.txt'. All those programs know how
to display '.txt' files.
Allison Randal
2008-08-27 06:33:33 UTC
Permalink
Post by James Keenan via RT
Post by Allison Randal
Generally recommend attaching patches as files ending in .patch (as
documented in docs/submissions.pod) for the sanity of the patch
monsters.
Well, since it's in the docs, I will withdraw the suggestion.
However, *I* am one of the patch monsters whose sanity you are concerned
with, and I have found that if the file ends in '.patch' I have to tell
my browser/mail client/newsreader what other program to open it with. I
don't have to do that if it ends in '.txt'. All those programs know how
to display '.txt' files.
You have to save the patch to disk before applying it anyway, which
means you can take advantage of text editors that properly
syntax-highlight .patch files (vim++, I'm sure emacs too, and probably
even Eclipse, Komodo, BBEdit...). That's a far more significant
advantage than the ability to view it as a flat-text file in the browser.
Post by James Keenan via RT
Would you accept '*.patch.txt' as a compromise?
Not as an official standard, but I've also never refused to apply a
patch because of the file extension. :)

Allison
James E Keenan
2008-08-26 01:52:50 UTC
Permalink
Post by Allison Randal
Post by James Keenan via RT
[BUG]. And I recommend submitting patches as email attachment ending in
: .txt (because that seems to render best in browsers, mail, news
interfaces).
Generally recommend attaching patches as files ending in .patch (as
documented in docs/submissions.pod) for the sanity of the patch
monsters. It makes patches immediately identifiable, versus large text
files of output from some debugging process.
Would you accept '*.patch.txt' as a compromise?
Erik Johansen
2008-08-26 06:44:31 UTC
Permalink
Post by James Keenan via RT
On my computer (OpenSuse 11.0) the Parrot Configure.pl hangs forever
when
checking for platfom support for AIO.
It appears to be a neverending sleep(1) loop in the check.
In the patch I have added a countdown to make it exit after some time,
anyway.
The patch looks reasonable to me and, at the very least, Does No Harm on
1. After you run 'perl Configure.pl' with this patch on your box, what
grep -ni AIO lib/Parrot/Config/Generated.pm
AIO is not in the file.

(I am not sure that this is the right conclusion. After all, opensuse
has /lib/libaio.so.1 & /lib/libaio.so.1.0.1 indicating that AIO is
supported. It may be more likely that the AIO works fine, but the signal gets
sent before the handler is set up. And that makes it sit waiting for a signal
that does not arrive. So a rewrite of the test program might be the real
solution.)
Post by James Keenan via RT
2. Your patch inspired me to check for other instances of 'sleep' in
the Parrot configuration system. I couldn't find any, which is a Good
Thing, IMHO.
[BUG]. And I recommend submitting patches as email attachment ending in
: .txt (because that seems to render best in browsers, mail, news
interfaces).
Thanks. I will make sure to use that in the future.
Post by James Keenan via RT
Can we get this patch tried out on a few more OSes?
Thank you very much.
kid51
--
Med venlig hilsen
Erik Johansen, Innovation & udvikling

Adapt A/S, Langebrogade 6E, 3. sal, 1411 København K, Tlf. +45 3341 1050
James Keenan via RT
2008-08-26 17:05:05 UTC
Permalink
Post by Erik Johansen
Post by James Keenan via RT
1. After you run 'perl Configure.pl' with this patch on your box,
what
Post by James Keenan via RT
grep -ni AIO lib/Parrot/Config/Generated.pm
AIO is not in the file.
(I am not sure that this is the right conclusion. After all, opensuse
has /lib/libaio.so.1 & /lib/libaio.so.1.0.1 indicating that AIO is
supported. It may be more likely that the AIO works fine, but the signal gets
sent before the handler is set up. And that makes it sit waiting for a signal
that does not arrive. So a rewrite of the test program might be the real
solution.)
Yes, this is a bit puzzling. With your patch applied, calling 'perl
Configure.pl' gives me this output:

auto::aio - Does your platform support AIO......................yes.

... and doing the grep I described above gives:

grep -in aio lib/Parrot/Config/Generated.pm
92: 'HAS_AIO' => 1,
110: 'aio' => 'define',

... and this is on two boxes (one Ubuntu, one Debian) where I'm sure I
never did anything special to install AIO.

And so even with your patch applied, when you run Configure.pl you don't
detect the presence of AIO -- am I understanding you correctly?

The probe file in question has not been substantively altered in four
years, so if you feel it should be rewritten, please feel free to submit
a different patch.

HTH

kid51
Erik Johansen
2008-08-27 06:19:48 UTC
Permalink
On my OpenSuse, it looks like this:

auto::aio - Does your platform support AIO...wrong signal
..................done.

So the fact that it exits the loop early, just makes it continue to the "wrong
signal" indication, and that marks it as not supported. After all it did not
meet the test to return the expected signal.

/Erik Johansen
Post by James Keenan via RT
Post by Erik Johansen
Post by James Keenan via RT
1. After you run 'perl Configure.pl' with this patch on your box,
what
Post by James Keenan via RT
grep -ni AIO lib/Parrot/Config/Generated.pm
AIO is not in the file.
(I am not sure that this is the right conclusion. After all, opensuse
has /lib/libaio.so.1 & /lib/libaio.so.1.0.1 indicating that AIO is
supported. It may be more likely that the AIO works fine, but the
signal gets
sent before the handler is set up. And that makes it sit waiting for a
signal
that does not arrive. So a rewrite of the test program might be the
real
solution.)
Yes, this is a bit puzzling. With your patch applied, calling 'perl
auto::aio - Does your platform support AIO......................yes.
grep -in aio lib/Parrot/Config/Generated.pm
92: 'HAS_AIO' => 1,
110: 'aio' => 'define',
... and this is on two boxes (one Ubuntu, one Debian) where I'm sure I
never did anything special to install AIO.
And so even with your patch applied, when you run Configure.pl you don't
detect the presence of AIO -- am I understanding you correctly?
The probe file in question has not been substantively altered in four
years, so if you feel it should be rewritten, please feel free to submit
a different patch.
HTH
kid51
--
Med venlig hilsen
Erik Johansen, Innovation & udvikling

Adapt A/S, Langebrogade 6E, 3. sal, 1411 København K, Tlf. +45 3341 1050
Patrick R. Michaud via RT
2008-09-04 13:33:45 UTC
Permalink
I just wanted to comment that I see this problem on my Kubuntu system as
well -- when running Configure.pl, I consistently get to the step for
AIO and things hang (until I press control-C):

...
auto::socklen_t - Determine whether there is
socklen_t................yes.
auto::env - Does your C library have setenv /
unsetenv.........both.
auto::aio - Does your platform support AIO...

Can we get this problem resolved soonish? The fact that this
configuration step hangs makes it more difficult to generate various
progress reports and automated testing items.

Thanks!

Pm
James Keenan via RT
2008-09-04 15:31:10 UTC
Permalink
Post by Patrick R. Michaud via RT
I just wanted to comment that I see this problem on my Kubuntu system as
well -- when running Configure.pl, I consistently get to the step for
...
auto::socklen_t - Determine whether there is
socklen_t................yes.
auto::env - Does your C library have setenv /
unsetenv.........both.
auto::aio - Does your platform support AIO...
Can we get this problem resolved soonish? The fact that this
configuration step hangs makes it more difficult to generate various
progress reports and automated testing items.
Patrick:

Does Erik's patch clear up the problem on your Kubuntu system? If so,
then please go ahead and commit it to trunk.

If it *doesn't* clear up the problem, then we need someone with deeper
knowledge about AIO than I, as this problem is in the C-probe rather
than in the Perl 5 surrounding it.

kid51
James Keenan via RT
2008-09-04 15:45:07 UTC
Permalink
In r30754 I temporarily SKIPped most of the tests in
t/steps/auto_aio-01.t so that you can have a free hand in patching
auto::aio.
Patrick R. Michaud
2008-09-04 18:26:17 UTC
Permalink
Post by James Keenan via RT
Post by Patrick R. Michaud via RT
I just wanted to comment that I see this problem on my Kubuntu system as
well -- when running Configure.pl, I consistently get to the step for
Does Erik's patch clear up the problem on your Kubuntu system? If so,
then please go ahead and commit it to trunk.
It does cause the auto::aio step to continue after about 10 seconds
with a message of "wrong signal".

1. I think 10 seconds might be a bit too long -- 4 or 5 might be better.
2. It would be nice if "wrong signal" was suppressed, or otherwise
incorporated into the output such that it didn't present a "break"
in the configuration display.

Pm
James Keenan via RT
2008-09-04 23:52:34 UTC
Permalink
Post by Patrick R. Michaud
It does cause the auto::aio step to continue after about 10 seconds
with a message of "wrong signal".
1. I think 10 seconds might be a bit too long -- 4 or 5 might be better.
2. It would be nice if "wrong signal" was suppressed, or otherwise
incorporated into the output such that it didn't present a "break"
in the configuration display.
I applied the patch attached, aio.in.revised.patch.txt, in r30771. I
set the 'sleep' to 4 seconds. All the tests have been reactivated.

This is a patch in the sense of "bandaid". What is it about the letter
'K' that means that this probe gives sloppy results on Kubuntu when on
Ubuntu it has built cleanly for me every day since I started building
Parrot? Haven't a clue, as purl would say. Anyone who knows more about
AIO please take a crack at this.

Thank you very much.
kid51
James Keenan via RT
2008-09-05 00:13:11 UTC
Permalink
Post by James Keenan via RT
Anyone who knows more about
AIO please take a crack at this.
I should also add that since I can't reproduce the "wrong signal" on
either of my OSes, someone on those OSes will have to take up the diagnosis.

kid51
Patrick R. Michaud
2008-09-05 01:29:13 UTC
Permalink
Post by James Keenan via RT
I applied the patch attached, aio.in.revised.patch.txt, in r30771. I
set the 'sleep' to 4 seconds. All the tests have been reactivated.
Thanks.
Post by James Keenan via RT
This is a patch in the sense of "bandaid". What is it about the letter
'K' that means that this probe gives sloppy results on Kubuntu when on
Ubuntu it has built cleanly for me every day since I started building
Parrot?
The problem only appeared for me in Kubuntu a few weeks ago, and
then only intermittently until a week or so ago. Prior to the
beginning of August Parrot had been building cleanly for me on
Kubuntu without any difficulty.

As one of the earlier messages suggested, I think it may just be a
race condition in the signal handling.

Pm
James Keenan via RT
2008-09-05 02:22:58 UTC
Permalink
FWIW, here is a data point: What happens on my Darwin/PPC (10.4) Mac at
auto::aio:

On Darwin, Configure.pl reports that AIO is unsupported. If I hack up
config/auto/aio.pm to print the content of the $@ inside
_first_probe_for_aio() -- i.e., expose what the C probe in
config/auto/aio/aio.in said --

$ svn diff config/auto/aio.pm
Index: config/auto/aio.pm
===================================================================
--- config/auto/aio.pm (revision 30771)
+++ config/auto/aio.pm (working copy)
@@ -47,7 +47,7 @@
my $libs = $conf->data->get('libs');
$conf->data->add( ' ', libs => '-lrt' );

- my $errormsg = _first_probe_for_aio($conf);
+ my $errormsg = _first_probe_for_aio($conf, $verbose);
if ( ! $errormsg ) {
my $test = $conf->cc_run(35);

@@ -79,6 +79,7 @@

sub _first_probe_for_aio {
my $conf = shift;
+ my $verbose = shift;
my $errormsg;
$conf->cc_gen('config/auto/aio/aio.in');
eval { $conf->cc_build(); };

... I get this output:

auto::aio - Does your platform support AIO...
/usr/bin/gcc -fno-common -no-cpp-precomp -pipe -I/opt/local/include
-pipe -fno-common -Wno-long-double -DHASATTRIBUTE_CONST
-DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL
-DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED
-DHASATTRIBUTE_WARN_UNUSED_RESULT -falign-functions=16
-fvisibility=hidden -W -Wall -Waggregate-return -Wcast-align -Wcast-qual
-Wchar-subscripts -Wcomment -Wdisabled-optimization -Wendif-labels
-Wextra -Wformat -Wformat-extra-args -Wformat-nonliteral
-Wformat-security -Wformat-y2k -Wimplicit -Wimport -Winit-self -Winline
-Winvalid-pch -Wmissing-braces -Wmissing-field-initializers
-Wno-missing-format-attribute -Wmissing-include-dirs -Wpacked
-Wparentheses -Wpointer-arith -Wreturn-type -Wsequence-point -Wno-shadow
-Wsign-compare -Wstrict-aliasing -Wstrict-aliasing=2 -Wswitch
-Wswitch-default -Wtrigraphs -Wundef -Wunknown-pragmas -Wno-unused
-Wvariadic-macros -Wwrite-strings -Wbad-function-cast
-Wdeclaration-after-statement -Wimplicit-function-declaration
-Wimplicit-int -Wmain -Wmissing-declarations -Wmissing-prototypes
-Wnested-externs -Wnonnull -I./include -c test_1120.c
test_1120.c: In function 'sighandler':
test_1120.c:26: error: 'struct __siginfo' has no member named 'si_ptr'
test_1120.c: In function 'main':
test_1120.c:40: error: 'SIGRTMIN' undeclared (first use in this function)
test_1120.c:40: error: (Each undeclared identifier is reported only once
test_1120.c:40: error: for each function it appears in.)
test_1120.c:40: error: 'SIGRTMAX' undeclared (first use in this function)
(no)
Setting Configuration Data:
(
verbose => undef,
);

Does your platform support
AIO.......................no.

This seems to indicate that my Mac truly does not support AIO. But it
may be that the probe in aio.in is simply badly designed. I don't know
enough about the subject to distinguish the two cases definitively.
(And I can't seem to find any Fink or Macports package that will install
AIO -- except a package surrounding CPAN module IO::AIO.)

kid51
James Keenan via RT
2008-09-06 02:08:34 UTC
Permalink
Post by James Keenan via RT
FWIW, here is a data point: What happens on my Darwin/PPC (10.4) Mac at
On Darwin, Configure.pl reports that AIO is unsupported.
Follow-up question: If I 'locate aio' on my Mac and come up with this
(excerpted) list of files:

/usr/include/aio.h
/usr/include/sys/aio.h
/usr/share/man/man2/aio_cancel.2
/usr/share/man/man2/aio_error.2
/usr/share/man/man2/aio_read.2
/usr/share/man/man2/aio_return.2
/usr/share/man/man2/aio_suspend.2
/usr/share/man/man2/aio_write.2

... what *else* would I need to have AIO available on Darwin?

Thank you very much.
kid51
Andy Dougherty
2008-09-06 23:45:16 UTC
Permalink
Post by James Keenan via RT
Post by James Keenan via RT
FWIW, here is a data point: What happens on my Darwin/PPC (10.4) Mac at
On Darwin, Configure.pl reports that AIO is unsupported.
Follow-up question: If I 'locate aio' on my Mac and come up with this
/usr/include/aio.h
/usr/include/sys/aio.h
/usr/share/man/man2/aio_cancel.2
/usr/share/man/man2/aio_error.2
/usr/share/man/man2/aio_read.2
/usr/share/man/man2/aio_return.2
/usr/share/man/man2/aio_suspend.2
/usr/share/man/man2/aio_write.2
... what *else* would I need to have AIO available on Darwin?
It looks like you already have it available. If you try with my patch in
verbose mode, what, exactly, goes wrong such that Configure.pl concludes
AIO is unsupported?
--
Andy Dougherty ***@lafayette.edu
James Keenan via RT
2008-09-07 03:19:56 UTC
Permalink
Post by Andy Dougherty
Post by James Keenan via RT
... what *else* would I need to have AIO available on Darwin?
It looks like you already have it available. If you try with my patch in
verbose mode, what, exactly, goes wrong such that Configure.pl concludes
AIO is unsupported?
See attached, run at r30847. Thanks.
kid51
Chromatic
2008-09-07 03:54:48 UTC
Permalink
Post by James Keenan via RT
Post by Andy Dougherty
Post by James Keenan via RT
... what *else* would I need to have AIO available on Darwin?
It looks like you already have it available. If you try with my patch in
verbose mode, what, exactly, goes wrong such that Configure.pl concludes
AIO is unsupported?
See attached, run at r30847. Thanks.
kid51
test_17787.c: In function 'main':
test_17787.c:45: error: 'SIGRTMIN' undeclared (first use in this function)
test_17787.c:45: error: (Each undeclared identifier is reported only once
test_17787.c:45: error: for each function it appears in.)
test_17787.c:46: error: 'SIGRTMAX' undeclared (first use in this function)

If they're not in signal.h in Darwin, where are they? (And if they're not in
signal.h in Darwin, can someone squelch the rumor that Mac OS X is a
Unix-like platform? POSIX 2001!)

... or we could use SIGUSR for the tests, I suppose. We're not using
real-time signals elsewhere in Parrot right now.

-- c
James Keenan via RT
2008-09-09 01:42:35 UTC
Permalink
Post by Chromatic
... or we could use SIGUSR for the tests, I suppose. We're not using
real-time signals elsewhere in Parrot right now.
All I can really say at this point is, "Patches welcome." From my
googling about SIGUSR, it appears we'd have to trap it as it causes a
'die' by default. But I don't now enough C at this point to write such
a handler.

kid51
Andy Dougherty
2008-09-09 12:46:33 UTC
Permalink
Post by Chromatic
test_17787.c:45: error: 'SIGRTMIN' undeclared (first use in this function)
test_17787.c:45: error: (Each undeclared identifier is reported only once
test_17787.c:45: error: for each function it appears in.)
test_17787.c:46: error: 'SIGRTMAX' undeclared (first use in this function)
If they're not in signal.h in Darwin, where are they? (And if they're not in
signal.h in Darwin, can someone squelch the rumor that Mac OS X is a
Unix-like platform? POSIX 2001!)
... or we could use SIGUSR for the tests, I suppose. We're not using
real-time signals elsewhere in Parrot right now.
Parrot's also not using AIO anywhere either, so the whole probe is kind of
pointless right now. Mainly, I was just hoping that a minor fix would
help solve Patrick's problem of Configure.pl hanging during the aio probe.
I don't know if it actually made any difference.

Anyway, here's a minimally disruptive patch to change SIGRTMIN to SIGUSR1.
I also got rid of the completely-unused logic to add
SIGRTMIN + atoi(argv[1]), since that no longer makes any sense.

This patch also gets rid of the probing for SIGRTMIN and SIGRTMAX. If
parrot actually wants to use them, it should get them from a separate
probe, rather than relying on them as a side effect of this test. At the
moment, parrot doesn't use either one, so this does not change any
functionality.

After this patch, the probe will still be useless, since aio still isn't
used anywhere, but perhaps it will now "pass" on Darwin and not hang
elsewhere.

diff -r -u parrot-current/config/auto/aio/aio.in parrot-andy/config/auto/aio/aio.in
--- parrot-current/config/auto/aio/aio.in 2008-09-08 08:38:49.000000000 -0400
+++ parrot-andy/config/auto/aio/aio.in 2008-09-09 07:45:03.000000000 -0400
@@ -36,14 +36,7 @@
int i = 42;
int cnt = 4;

- /* For internal use, we usually use
- SIGRTMIN + argv[1].
- Usually, that's set to
- SIGRTMIN + 1
- by the calling program.
- */
- my_sig = SIGRTMIN + atoi(argv[1]);
- printf("SIGRTMIN=%d SIGRTMAX=%d\n", SIGRTMIN, SIGRTMAX);
+ my_sig = SIGUSR1;

fd = open("MANIFEST", O_RDONLY);
if (fd < 0)
diff -r -u parrot-svn/config/auto/aio.pm parrot-andy/config/auto/aio.pm
--- parrot-svn/config/auto/aio.pm 2008-09-08 08:38:49.000000000 -0400
+++ parrot-andy/config/auto/aio.pm 2008-09-09 07:46:14.000000000 -0400
@@ -49,14 +49,13 @@

my $errormsg = _first_probe_for_aio($conf, $verbose);
if ( ! $errormsg ) {
- my $test = $conf->cc_run(1); # Use signal RTMIN + 1
+ my $test = $conf->cc_run();

# if the test is failing with sigaction err
# we should repeat it with a different signal number
# This is currently not implemented.
if (
- $test =~ /SIGRTMIN=(\d+)\sSIGRTMAX=(\d+)\n
- INFO=42\n
+ $test =~ /INFO=42\n
ok/x
)
{
@@ -66,8 +65,6 @@
$conf->data->set(
aio => 'define',
HAS_AIO => 1,
- D_SIGRTMIN => $1,
- D_SIGRTMAX => $2,
);
}
else {
--
Andy Dougherty ***@lafayette.edu
Will Coleda
2008-09-09 12:56:59 UTC
Permalink
Post by Andy Dougherty
Parrot's also not using AIO anywhere either, so the whole probe is kind of
pointless right now.
Instead of spending time fixing a probe that isn't being used, we
should rip it out. If we eventually need it again, we can start from
here, but there's no point in probing for features that we never use.
It's wasting developer (and less importantly, CPU) time better spent
elsewhere.

Regards.
--
Will "Coke" Coleda
Andy Dougherty
2008-09-09 14:01:34 UTC
Permalink
Post by Will Coleda
Post by Andy Dougherty
Parrot's also not using AIO anywhere either, so the whole probe is kind of
pointless right now.
Instead of spending time fixing a probe that isn't being used, we
should rip it out. If we eventually need it again, we can start from
here, but there's no point in probing for features that we never use.
It's wasting developer (and less importantly, CPU) time better spent
elsewhere.
In general, I'd agree. However, in this particular case, fixing it was
easier for me than figuring out all the steps necessary to rip it out.
--
Andy Dougherty ***@lafayette.edu
James Keenan via RT
2008-09-09 15:00:37 UTC
Permalink
On Tue, Sep 9, 2008 at 8:46 AM, Andy Dougherty
Post by Andy Dougherty
Parrot's also not using AIO anywhere either, so the whole probe is
kind of
Post by Andy Dougherty
pointless right now.
Instead of spending time fixing a probe that isn't being used, we
should rip it out. If we eventually need it again, we can start from
here, but there's no point in probing for features that we never use.
It's wasting developer (and less importantly, CPU) time better spent
elsewhere.
Coke: I lean toward this position -- less is more -- but will implement
whatever is decided. Perhaps you can discuss this in parrotsketch today?

Thank you very much.
kid51
Allison Randal
2008-09-09 22:14:04 UTC
Permalink
Post by Will Coleda
Instead of spending time fixing a probe that isn't being used, we
should rip it out. If we eventually need it again, we can start from
here, but there's no point in probing for features that we never use.
It's wasting developer (and less importantly, CPU) time better spent
elsewhere.
Generally agreed. In this case, hold this ticket for the I/O milestone,
which is next (sometime in the next few days). I've added it to the I/O
tasklist.

In the meantime, let's get Andy's patch applied (if it isn't already).

Allison
James Keenan via RT
2008-09-10 01:22:33 UTC
Permalink
Post by Allison Randal
Generally agreed. In this case, hold this ticket for the I/O milestone,
which is next (sometime in the next few days). I've added it to the I/O
tasklist.
In the meantime, let's get Andy's patch applied (if it isn't already).
I extracted the attached patch from email text and applied it in r30946.
All
tests pass, but note that I still don't get correct detection of AIO
capabilities on Darwin/PPC (OS X 10.4). The message I get with
verbose-step=auto::aio is in the second attachment.

Ticket remains open. Thanks to all who have contributed so far.

kid51
James Keenan via RT
2008-09-10 02:54:08 UTC
Permalink
Post by James Keenan via RT
I extracted the attached patch from email text and applied it in r30946.
For some reason, the first attachment -- Andy's patch -- didn't get
attached. Trying again.
Andrew Dougherty
2008-09-10 16:09:19 UTC
Permalink
Post by James Keenan via RT
Post by Allison Randal
Generally agreed. In this case, hold this ticket for the I/O milestone,
which is next (sometime in the next few days). I've added it to the I/O
tasklist.
In the meantime, let's get Andy's patch applied (if it isn't already).
I extracted the attached patch from email text and applied it in r30946.
All
tests pass, but note that I still don't get correct detection of AIO
capabilities on Darwin/PPC (OS X 10.4). The message I get with
verbose-step=auto::aio is in the second attachment.
auto::aio - Does your platform support AIO...
/usr/bin/gcc [-options ... ] -I./include -c test_19186.c
c++ -undefined dynamic_lookup test_19186.o -o test_19186 -lm -lrt
/usr/bin/ld: can't locate file for: -lrt
That's another easy one. The test assumes that all platforms have -lrt
and that all platforms have to link with it for this test. Your system
clearly doesn't have -lrt, so the link fails. If you just delete the line
that adds in -lrt, I'll bet the test succeeds.

Generally, Configure shouldn't be unconditionally adding libraries. A
better idiom is probably to try without, and then try with only if
necessary. Something like this:

diff -r -u parrot-svn/config/auto/aio.pm parrot-cc/config/auto/aio.pm
--- parrot-svn/config/auto/aio.pm 2008-09-10 11:06:19.000000000 -0400
+++ parrot-cc/config/auto/aio.pm 2008-09-10 11:53:31.000000000 -0400
@@ -45,9 +45,14 @@

my $verbose = $conf->options->get('verbose');
my $libs = $conf->data->get('libs');
- $conf->data->add( ' ', libs => '-lrt' );
-
my $errormsg = _first_probe_for_aio($conf, $verbose);
+ if ($errormsg) {
+ # Linux, at least, needs to add -lrt to $libs.
+ print " (Trying again with -lrt) " if $verbose;
+ $conf->data->add( ' ', libs => '-lrt' );
+ $errormsg = _first_probe_for_aio($conf, $verbose);
+ }
+
if ( ! $errormsg ) {
my $test = $conf->cc_run();
--
Andy Dougherty ***@lafayette.edu
James Keenan via RT
2008-09-11 00:02:25 UTC
Permalink
Post by Andrew Dougherty
That's another easy one. The test assumes that all platforms have -lrt
and that all platforms have to link with it for this test. Your system
clearly doesn't have -lrt, so the link fails. If you just delete the line
that adds in -lrt, I'll bet the test succeeds.
Generally, Configure shouldn't be unconditionally adding libraries. A
better idiom is probably to try without, and then try with only if
The principle sounds good. I applied the patch and, as predicted, it
DTRT on Linux, as this verbose output for auto::aio on Linux demonstrates.

Unfortunately, it didn't cause AIO to be located on Darwin -- even
though it changed the error message. The handles to the error files
were opened, but the .out, .cco and .ldo files were all empty.

$ ls -ltr test_*
-rw-r--r-- 1 jimk jimk 3424 Sep 10 19:58 test_26632.o
-rw-r--r-- 1 jimk jimk 0 Sep 10 19:58 test_26632.ldo
-rw-r--r-- 1 jimk jimk 0 Sep 10 19:58 test_26632.cco
-rw-r--r-- 1 jimk jimk 1330 Sep 10 19:58 test_26632.c
-rw-r--r-- 1 jimk jimk 0 Sep 10 19:58 test_26632.out
-rwxr-xr-x 1 jimk jimk 18148 Sep 10 19:58 test_26632


Thank you very much.
kid51
Andy Dougherty
2008-09-11 03:06:30 UTC
Permalink
Post by James Keenan via RT
Post by Andrew Dougherty
That's another easy one. The test assumes that all platforms have -lrt
and that all platforms have to link with it for this test. Your system
clearly doesn't have -lrt, so the link fails. If you just delete the
line
Post by Andrew Dougherty
that adds in -lrt, I'll bet the test succeeds.
Generally, Configure shouldn't be unconditionally adding libraries. A
better idiom is probably to try without, and then try with only if
The principle sounds good. I applied the patch and, as predicted, it
DTRT on Linux, as this verbose output for auto::aio on Linux demonstrates.
Unfortunately, it didn't cause AIO to be located on Darwin -- even
though it changed the error message. The handles to the error files
were opened, but the .out, .cco and .ldo files were all empty.
It could be that aio just doesn't work on your system -- or at least aio
as implemented by the author of this test.

If you care to diagnose it further, you could try running the test_26632
executable directly from the command line and see what the output is. Or
you could alter config/auto/aio.pm to output the errors in this case.
However, I'm unsure if it's worth it. You'll might learn a little more
about why it's failing, but you may not be able to do anything to fix it.
Post by James Keenan via RT
Post by Andrew Dougherty
$ ls -ltr test_*
-rw-r--r-- 1 jimk jimk 3424 Sep 10 19:58 test_26632.o
-rw-r--r-- 1 jimk jimk 0 Sep 10 19:58 test_26632.ldo
-rw-r--r-- 1 jimk jimk 0 Sep 10 19:58 test_26632.cco
-rw-r--r-- 1 jimk jimk 1330 Sep 10 19:58 test_26632.c
-rw-r--r-- 1 jimk jimk 0 Sep 10 19:58 test_26632.out
-rwxr-xr-x 1 jimk jimk 18148 Sep 10 19:58 test_26632
--
Andy Dougherty ***@lafayette.edu
Patrick R. Michaud
2008-09-09 12:54:36 UTC
Permalink
Post by Andy Dougherty
Parrot's also not using AIO anywhere either, so the whole probe is kind of
pointless right now. Mainly, I was just hoping that a minor fix would
help solve Patrick's problem of Configure.pl hanging during the aio probe.
I don't know if it actually made any difference.
The minor fix (preventing the infinite loop in the probe) has
made a _huge_ difference, thanks.

Pm
Andy Dougherty
2008-09-05 17:16:56 UTC
Permalink
Post by Erik Johansen
Post by James Keenan via RT
I applied the patch attached, aio.in.revised.patch.txt, in r30771. I
set the 'sleep' to 4 seconds. All the tests have been reactivated.
Thanks.
Post by James Keenan via RT
This is a patch in the sense of "bandaid". What is it about the letter
'K' that means that this probe gives sloppy results on Kubuntu when on
Ubuntu it has built cleanly for me every day since I started building
Parrot?
The problem only appeared for me in Kubuntu a few weeks ago, and
then only intermittently until a week or so ago. Prior to the
beginning of August Parrot had been building cleanly for me on
Kubuntu without any difficulty.
As one of the earlier messages suggested, I think it may just be a
race condition in the signal handling.
It's a wacky test in many respects. For one thing, it tests using
signal number '35' without any regard for what that signal might
acutally mean. On Solaris, for example, 35 is 'SIGFREEZE', which is
almost certainly not what was intended.

I suspect that on someone's Linux system, SIGRTMIN got reported as 34,
and so the test just hard-coded '35'. It's quite possible that signal
35 means something different on recent versions of Kubuntu.

This patch takes the following small steps:

First, I replaced the
retval = *(int*)i->si_ptr;
line by
retval = *(int*)i->si_value.sival_ptr;
I've never fiddled with this stuff before, but it looks like the si_ptr
#define is not necessarily very portable. I replaced it by the si_value
and sival_ptr fields, which I hope are slightly more portable.

Second, it moves the small step of moving the logic of finding
SIGRTMIN + 1 into the C program, where it's trivial.

Next, it adds in an else branch for the case where the program builds
but does not run successfully.

Finally, made sure the 'aio' and 'HAS_AIO' entries are always set to
some value.

I haven't looked for race conditions at all, but with this patch, I'll at
least be more confident that it's trying to do what we think it's trying
to do.

diff -r -u parrot-current/config/auto/aio/aio.in parrot-andy/config/auto/aio/aio.in
--- parrot-current/config/auto/aio/aio.in 2008-09-05 08:13:19.000000000 -0400
+++ parrot-andy/config/auto/aio/aio.in 2008-09-05 13:04:03.000000000 -0400
@@ -23,7 +23,7 @@
{
if (s == my_sig) {
flag = s;
- retval = *(int*)i->si_ptr;
+ retval = *(int*)i->si_value.sival_ptr;
}
}

@@ -36,7 +36,13 @@
int i = 42;
int cnt = 4;

- my_sig = atoi(argv[1]);
+ /* For internal use, we usually use
+ SIGRTMIN + argv[1].
+ Usually, that's set to
+ SIGRTMIN + 1
+ by the calling program.
+ */
+ my_sig = SIGRTMIN + atoi(argv[1]);
printf("SIGRTMIN=%d SIGRTMAX=%d\n", SIGRTMIN, SIGRTMAX);

fd = open("MANIFEST", O_RDONLY);
diff -r -u parrot-current/config/auto/aio.pm parrot-andy/config/auto/aio.pm
--- parrot-current/config/auto/aio.pm 2008-08-31 12:15:34.000000000 -0400
+++ parrot-andy/config/auto/aio.pm 2008-09-05 12:08:23.000000000 -0400
@@ -49,10 +49,11 @@

my $errormsg = _first_probe_for_aio($conf);
if ( ! $errormsg ) {
- my $test = $conf->cc_run(35);
+ my $test = $conf->cc_run(1); # Use signal RTMIN + 1

# if the test is failing with sigaction err
# we should repeat it with a different signal number
+ # This is currently not implemented.
if (
$test =~ /SIGRTMIN=(\d+)\sSIGRTMAX=(\d+)\n
INFO=42\n
@@ -69,6 +70,9 @@
D_SIGRTMAX => $2,
);
}
+ else {
+ $self->_handle_error_case($conf, $libs, $verbose);
+ }
}
else {
$self->_handle_error_case($conf, $libs, $verbose);
@@ -88,7 +92,11 @@

sub _handle_error_case {
my ($self, $conf, $libs, $verbose) = @_;
- $conf->data->set( libs => $libs );
+ $conf->data->set(
+ aio => undef,
+ HAS_AIO => 0,
+ );
+ $conf->data->set( libs => $libs ); # Restore old values
print " (no) " if $verbose;
$self->set_result('no');
}
--
Andy Dougherty ***@lafayette.edu
James Keenan via RT
2008-09-06 02:05:49 UTC
Permalink
Post by Andy Dougherty
First, I replaced the
retval = *(int*)i->si_ptr;
line by
retval = *(int*)i->si_value.sival_ptr;
I've never fiddled with this stuff before, but it looks like the si_ptr
#define is not necessarily very portable. I replaced it by the si_value
and sival_ptr fields, which I hope are slightly more portable.
Second, it moves the small step of moving the logic of finding
SIGRTMIN + 1 into the C program, where it's trivial.
Next, it adds in an else branch for the case where the program builds
but does not run successfully.
Finally, made sure the 'aio' and 'HAS_AIO' entries are always set to
some value.
I haven't looked for race conditions at all, but with this patch, I'll at
least be more confident that it's trying to do what we think it's trying
to do.
Thanks, Andy. Applied in r30800 after testing on Linux and Darwin.
a***@ippimail.com
2008-09-05 15:35:09 UTC
Permalink
Post by James Keenan via RT
This is a patch in the sense of "bandaid". What is it about the letter
'K' that means that this probe gives sloppy results on Kubuntu when on
Ubuntu it has built cleanly for me every day
Something to do with Gnome, since that's the major difference between the
two?



--

Email and shopping with the feelgood factor!
55% of income to good causes. http://www.ippimail.com
a***@ippimail.com
2008-09-05 15:39:15 UTC
Permalink
Post by James Keenan via RT
This is a patch in the sense of "bandaid". What is it about the letter
'K' that means that this probe gives sloppy results on Kubuntu when on
Ubuntu it has built cleanly for me every day since I started
Something to do with KDE vs Gnome, since that's the major difference?
Perhaps KDE's screen-saver mechanism's sabotaging you?


--

Email and shopping with the feelgood factor!
55% of income to good causes. http://www.ippimail.com
Jim Keenan
2008-09-05 17:35:02 UTC
Permalink
I'll try this out on Darwin and (Debian) Linux this weekend and see what happens. Thanks.
Jarkko Hietaniemi
2008-12-17 12:48:20 UTC
Permalink
147-+
rurban, can this =item be deleted?
$ grep -in -A2 -B2 aio config/init/hints/dec_osf.pm 28-
$libs .= ' -lpthread';
29- }
30: if ( $libs !~ /-laio/ ) {
31: $libs .= ' -laio';
32- }
33- $conf->data->set( libs => $libs );
Jarkko, are you available to comment on this?
Well, feel free to delete since Parrot doesn't even build ATM in dec-osf ...
Thank you very much.
kid51
Loading...