X-Git-Url: https://perl5.git.perl.org/perl5.git/blobdiff_plain/52960e22f7473ebbba8ff26ac58fdc25d2401bd0..839c1407d250d7c1cabbabe92d598c29d94077e8:/pod/perltodo.pod diff --git a/pod/perltodo.pod b/pod/perltodo.pod index b79980e..81afdb0 100644 --- a/pod/perltodo.pod +++ b/pod/perltodo.pod @@ -64,12 +64,6 @@ implements a very basic check for pod files, but the errors it discovers aren't found by podchecker. Add this check to podchecker, get rid of checkpods and have C use podchecker. -=head2 perlmodlib.PL rewrite - -Currently perlmodlib.PL needs to be run from a source directory where perl -has been built, or some modules won't be found, and others will be -skipped. Make it run from a clean perl source tree (so it's reproducible). - =head2 Parallel testing (This probably impacts much more than the core: also the Test::Harness @@ -163,6 +157,15 @@ do so. Test it with older perl releases, and fix the problems you find. To make a minimal perl distribution, it's useful to look at F. +=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. + =head2 Improving C Investigate whether C could share aggregates properly with @@ -548,6 +551,93 @@ These tasks would need C knowledge, and roughly the level of knowledge of 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 implementation, F +contains a function C which in conjunction with C is +used to wrap the C functions C, C, C, +C, C and C. 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 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 for C, create a +pipe, store the reader in one, the writer in the other + +=item 3 + +In the "safe" signal handler (C/C), if +the C pointer non-C, and the writer file handle is open, + +=over 8 + +=item 1 + +serialise signal number, C (or at least the parts we care +about) into a small auto char buff + +=item 2 + +C 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 processing, if there are "signals on +the pipe", read the data out, deserialise, build the Perl structures on +the stack (code in C, the "unsafe" handler), and call as +usual. + +=back + +I think that this gets us decent C support, without the current risk +of running Perl code inside the signal handler context. (With all the dangers +of things like C 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; @@ -664,32 +754,6 @@ only the interpretation of non-ASCII characters, and not for the script file handle. To make it work needs some investigation of the ordering of function calls during startup, and (by implication) a bit of tweaking of that order. -=head2 Propagate const outwards from Perl_moreswitches() - -Change 32057 changed the parameter and return value of C -from to . It should now be possible to propagate -const-correctness outwards to C, C -and C. - -=head2 Duplicate logic in S_method_common() and Perl_gv_fetchmethod_autoload() - -A comment in C notes - - /* This code tries to figure out just what went wrong with - gv_fetchmethod. It therefore needs to duplicate a lot of - the internals of that function. We can't move it inside - Perl_gv_fetchmethod_autoload(), however, since that would - cause UNIVERSAL->can("NoSuchPackage::foo") to croak, and we - don't want that. - */ - -If C gets rewritten to take (more) flag bits, -then it ought to be possible to move the logic from C to -the "right" place. When making this change it would probably be good to also -pass in at least the method name length, if not also pre-computed hash values -when known. (I'm contemplating a plan to pre-compute hash values for common -fixed strings such as C and pass them in to functions.) - =head2 Organize error messages Perl's diagnostics (error messages, see L) could use @@ -909,16 +973,100 @@ See also L. =head2 Investigate PADTMP hash pessimisation The peephole optimier converts constants used for hash key lookups to shared -hash key scalars. Under ithreads, something is undoing this work. See +hash key scalars. Under ithreads, something is undoing this work. See http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2007-09/msg00793.html +=head2 Store the current pad in the OP slab allocator + +=for clarification +I hope that I got that "current pad" part correct + +Currently we leak ops in various cases of parse failure. I suggested that we +could solve this by always using the op slab allocator, and walking it to +free ops. Dave comments that as some ops are already freed during optree +creation one would have to mark which ops are freed, and not double free them +when walking the slab. He notes that one problem with this is that for some ops +you have to know which pad was current at the time of allocation, which does +change. I suggested storing a pointer to the current pad in the memory allocated +for the slab, and swapping to a new slab each time the pad changes. Dave thinks +that this would work. + =head2 repack the optree Repacking the optree after execution order is determined could allow -removal of NULL ops, and optimal ordering of OPs wrt cache-line -filling. The slab allocator could be reused for this purpose. +removal of NULL ops, and optimal ordering of OPs with respect to cache-line +filling. The slab allocator could be reused for this purpose. I think that +the best way to do this is to make it an optional step just before the +completed optree is attached to anything else, and to use the slab allocator +unchanged, so that freeing ops is identical whether or not this step runs. +Note that the slab allocator allocates ops downwards in memory, so one would +have to actually "allocate" the ops in reverse-execution order to get them +contiguous in memory in execution order. + +See http://www.nntp.perl.org/group/perl.perl5.porters/2007/12/msg131975.html + +Note that running this copy, and then freeing all the old location ops would +cause their slabs to be freed, which would eliminate possible memory wastage if +the previous suggestion is implemented, and we swap slabs more frequently. + +=head2 eliminate incorrect line numbers in warnings + +This code + + use warnings; + my $undef; + + if ($undef == 3) { + } elsif ($undef == 0) { + } -http://www.nntp.perl.org/group/perl.perl5.porters/2007/12/msg131975.html +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. + +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 and the C, hence C still +reports that the currently executing line is line 4. The solution was to inject +a nextstate OPs for each C, 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 (although the C case is the +most common and the most confusing). Ideally this code + + use warnings; + my $undef; + + my $a = $undef + 1; + my $b + = $undef + + 1; + +would produce this output + + Use of uninitialized value $undef in addition (+) at wrong.pl line 4. + Use of uninitialized value $undef in addition (+) at wrong.pl line 7. + +(rather than lines 4 and 5), but this would seem to require every OP to carry +(at least) line number information. + +What might work is to have an optional line number in memory just before the +BASEOP structure, with a flag bit in the op to say whether it's present. +Initially during compile every OP would carry its line number. Then add a late +pass to the optimiser (potentially combined with L) which +looks at the two ops on every edge of the graph of the execution path. If +the line number changes, flags the destination OP with this information. +Once all paths are traced, replace every op with the flag with a +nextstate-light op (that just updates C), which in turn then passes +control on to the true op. All ops would then be replaced by variants that +do not store the line number. (Which, logically, why it would work best in +conjunction with L, 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