To make a minimal perl distribution, it's useful to look at
F<t/lib/commonsense.t>.
+=head2 Bundle dual life modules in ext/
+
+For maintenance (and branch merging) reasons, it would be useful to move
+some architecture-independent dual-life modules from lib/ to ext/, if this
+has no negative impact on the build of perl itself.
+
+However, we need to make sure that they are still installed in
+architecture-independent directories by C<make install>.
+
=head2 Improving C<threads::shared>
Investigate whether C<threads::shared> could share aggregates properly with
the perl API that comes from writing modules that use XS to interface to
C.
+=head2 investigate removing int_macro_int from POSIX.xs
+
+As a hang over from the original C<constant> implementation, F<POSIX.xs>
+contains a function C<int_macro_int> which in conjunction with C<AUTOLOAD> is
+used to wrap the C functions C<WEXITSTATUS>, C<WIFEXITED>, C<WIFSIGNALED>,
+C<WIFSTOPPED>, C<WSTOPSIG> and C<WTERMSIG>. It's probably worth replacing
+this complexity with 5 simple direct wrappings of those 5 functions.
+
+However, it would be interesting if someone could measure the memory usage
+before and after, both for the case of C<use POSIX();> and the case of
+actually calling the Perl space functions.
+
+=head2 safely supporting POSIX SA_SIGINFO
+
+Some years ago Jarkko supplied patches to provide support for the POSIX
+SA_SIGINFO feature in Perl, passing the extra data to the Perl signal handler.
+
+Unfortunately, it only works with "unsafe" signals, because under safe
+signals, by the time Perl gets to run the signal handler, the extra
+information has been lost. Moreover, it's not easy to store it somewhere,
+as you can't call mutexs, or do anything else fancy, from inside a signal
+handler.
+
+So it strikes me that we could provide safe SA_SIGINFO support
+
+=over 4
+
+=item 1
+
+Provide global variables for two file descriptors
+
+=item 2
+
+When the first request is made via C<sigaction> for C<SA_SIGINFO>, create a
+pipe, store the reader in one, the writer in the other
+
+=item 3
+
+In the "safe" signal handler (C<Perl_csighandler()>/C<S_raise_signal()>), if
+the C<siginfo_t> pointer non-C<NULL>, and the writer file handle is open,
+
+=over 8
+
+=item 1
+
+serialise signal number, C<struct siginfo_t> (or at least the parts we care
+about) into a small auto char buff
+
+=item 2
+
+C<write()> that (non-blocking) to the writer fd
+
+=over 12
+
+=item 1
+
+if it writes 100%, flag the signal in a counter of "signals on the pipe" akin
+to the current per-signal-number counts
+
+=item 2
+
+if it writes 0%, assume the pipe is full. Flag the data as lost?
+
+=item 3
+
+if it writes partially, croak a panic, as your OS is broken.
+
+=back
+
+=back
+
+=item 4
+
+in the regular C<PERL_ASYNC_CHECK()> processing, if there are "signals on
+the pipe", read the data out, deserialise, build the Perl structures on
+the stack (code in C<Perl_sighandler()>, the "unsafe" handler), and call as
+usual.
+
+=back
+
+I think that this gets us decent C<SA_SIGINFO> support, without the current risk
+of running Perl code inside the signal handler context. (With all the dangers
+of things like C<malloc> corruption that that currently offers us)
+
+For more information see the thread starting with this message:
+http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2008-03/msg00305.html
+
=head2 autovivification
Make all autovivification consistent w.r.t LVALUE/RVALUE and strict/no strict;
} elsif ($undef == 0) {
}
-produces this output
+used to produce this output:
Use of uninitialized value in numeric eq (==) at wrong.pl line 4.
Use of uninitialized value in numeric eq (==) at wrong.pl line 4.
-Clearly the line of the second warning is misreported - it should be line 5.
-
-The problem arises because there is no nextstate op between the execution of
-the C<if> and the C<elsif>, hence C<PL_curcop> still reports that the currently
-executing line is line 4. The solution might be to inject (somehow) more
-nextstate ops, one for each C<elsif>.
+where the line of the second warning was misreported - it should be line 5.
+Rafael fixed this - the problem arose because there was no nextstate OP
+between the execution of the C<if> and the C<elsif>, hence C<PL_curcop> still
+reports that the currently executing line is line 4. The solution was to inject
+a nextstate OPs for each C<elsif>, although it turned out that the nextstate
+OP needed to be a nulled OP, rather than a live nextstate OP, else other line
+numbers became misreported. (Jenga!)
The problem is more general than C<elsif> (although the C<elsif> case is the
most common and the most confusing). Ideally this code
conjunction with L</repack the optree>, as that is already copying/reallocating
all the OPs)
+(Although I should note that we're not certain that doing this for the general
+case is worth it)
+
=head2 optimize tail-calls
Tail-calls present an opportunity for broadly applicable optimization;
projects / p5sagit/p5-mst-13.2.git / blobdiff