into a file, change it to build an C<%Is> hash and require it. Maybe just put
it into F<test.pl>. Throw in the handy tainting subroutines.
-=head2 merge common code in installperl and installman
-
-There are some common subroutines and a common C<BEGIN> block in F<installperl>
-and F<installman>. These should probably be merged. It would also be good to
-check for duplication in all the utility scripts supplied in the source
-tarball. It might be good to move them all to a subdirectory, but this would
-require careful checking to find all places that call them, and change those
-correctly.
-
=head2 common test code for timed bail out
Write portable self destruct code for tests to stop them burning CPU in
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
There's a similar problem with SelfLoader.
+=head2 profile installman
+
+The F<installman> script is slow. All it is doing text processing, which we're
+told is something Perl is good at. So it would be nice to know what it is doing
+that is taking so much CPU, and where possible address it.
+
+
=head1 Tasks that need a little sysadmin-type knowledge
Or if you prefer, tasks that you would learn from, and broaden your skills
want to determine what ops I<really> are the most commonly used. And in turn
suggest evictions and promotions to achieve a better F<pp_hot.c>.
+One piece of Perl code that might make a good testbed is F<installman>.
+
=head2 Allocate OPs from arenas
Currently all new OP structures are individually malloc()ed and free()d.
the perl API that comes from writing modules that use XS to interface to
C.
+=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;
The old perltodo notes "Look at the "reification" code in C<av.c>".
-=head2 The yada yada yada operators
-
-Perl 6's Synopsis 3 says:
-
-I<The ... operator is the "yada, yada, yada" list operator, which is used as
-the body in function prototypes. It complains bitterly (by calling fail)
-if it is ever executed. Variant ??? calls warn, and !!! calls die.>
-
-Those would be nice to add to Perl 5. That could be done without new ops.
-
=head2 Virtualize operating system access
Implement a set of "vtables" that virtualizes operating system access
projects / p5sagit/p5-mst-13.2.git / blobdiff