Re: perlio_fd_refcnt
On Fri, 24 Jun 2005 23:26:56 +0100, Nicholas Clark [EMAIL PROTECTED] wrote:
Would it make sense to replace the hardwired 2048 file descriptor reference
count array (used in perlio.c, defined in perlvars.h)
In in favour of lifting hard coded limits, but I'd not like that to cause
speed concerns. How about a stic set of, say, 32 fd's, and the rest fully
dynamic?
PERLVARA(Gperlio_fd_refcnt, 2048, int) /* PERLIO_MAX_REFCOUNTABLE_FD */
with 2 global variables (both protected by the PerlIO_mutex),
one a pointer to a dynamically allocated array, the other its length?
This would seem more flexible than the current arrangement, and would
probably use less memory in the general case.
For the various configurations of perl, are global variables always global
to perl${exe} ? Or can they end up in a shared library and hence have to
stay the same size to maintain binary compatibility?
(I'm looking at 8k of fd reference count array in every perl process ever
started and wondering if it might go on a diet)
Nicholas Clark
--
H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/)
using Perl 5.6.2, 5.8.0, 5.8.5, 5.9.2 on HP-UX 10.20, 11.00 11.11,
AIX 4.3 5.2, SuSE 9.2 9.3, and Cygwin. http://www.cmve.net/~merijn
Smoking perl: http://www.test-smoke.org,perl QA: http://qa.perl.org
reports to: [EMAIL PROTECTED],perl-qa@perl.org
Smoke [5.9.3] 24978 FAIL(F) bsd/os 4.1 (i386/1 cpu)
Automated smoke report for 5.9.3 patch 24978 fixit.xs4all.nl: Pentium II (i386/1 cpu) onbsd/os - 4.1 using cc version egcs-2.91.66 19990314 (egcs-1.1.2 release) smoketime 4 hours 4 minutes (average 2 hours 2 minutes) Summary: FAIL(F) O = OK F = Failure(s), extended report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during: - = unknown or N/A c = Configure, m = make, M = make (after miniperl), t = make test-prep 24978 Configuration (common) none --- - F F - - -Duse64bitint O O - - | | | +- PERLIO = perlio -DDEBUGGING | | +--- PERLIO = stdio -DDEBUGGING | +- PERLIO = perlio +--- PERLIO = stdio Failures: (common-args) none [stdio/perlio] -Duse64bitint ../t/op/int.t...FAILED 11 -- Report by Test::Smoke v1.19_67 build 842 running on perl 5.00503 (Reporter v0.019 / Smoker v0.023)
problem building latest perl (24978) on win32
Dear all, when building with ITHREADS, MULTIPLICITY, IMP_SYS turned off, and PERL_MALLOC, PERLIO turned on, following linker error happens: link -dll -def:perldll.def -base:0x2800 -out:..\perl59.dll @[EMAIL PROTECTED]:\Temp\nmb00668.^M perldll.def : error LNK2001: unresolved external symbol PL_dumper_fd^M ..\perl59.lib : fatal error LNK1120: 1 unresolved externals^M LINK : fatal error LNK1141: failure during build of exports file^M NMAKE : fatal error U1077: 'link' : return code '0x475'^M Stop.^M (miniperl is built okay) could you please anyone advice how this should be fixed? TIA. Vadim.
Re: problem building latest perl (24978) on win32
On Sat, Jun 25, 2005 at 06:05:31PM -0400, vadim wrote:
Dear all,
when building with ITHREADS, MULTIPLICITY, IMP_SYS turned off, and
PERL_MALLOC, PERLIO turned on, following linker error happens:
link -dll -def:perldll.def -base:0x2800 -out:..\perl59.dll
@[EMAIL PROTECTED]:\Temp\nmb00668.^M
perldll.def : error LNK2001: unresolved external symbol PL_dumper_fd^M
..\perl59.lib : fatal error LNK1120: 1 unresolved externals^M
LINK : fatal error LNK1141: failure during build of exports file^M
NMAKE : fatal error U1077: 'link' : return code '0x475'^M
Stop.^M
(miniperl is built okay)
could you please anyone advice how this should be fixed?
Aargh. Can anyone figure out a way to automate this? I think adding
this to makedef.pl will do it:
unless ($define{'DEBUG_LEAKING_SCALARS_FORK_DUMP'}) {
skip_symbols [qw(
PL_dumper_fd
)];
}
Does this fix it?
Nicholas Clark
Re: problem building latest perl (24978) on win32
Aargh. Can anyone figure out a way to automate this? I think adding
this to makedef.pl will do it:
unless ($define{'DEBUG_LEAKING_SCALARS_FORK_DUMP'}) {
skip_symbols [qw(
PL_dumper_fd
)];
}
Does this fix it?
yes, that error gone...
thanks for quick responce.
BTW, given that Compress::Zlib is now in the core (which is a good thing
IMO) is it possible to export zlib functions also, so to reuse code
when linking with other software requiring it?
Vadim.
Re: problem building latest perl (24978) on win32
On Sat, Jun 25, 2005 at 07:59:40PM -0400, vadim wrote: BTW, given that Compress::Zlib is now in the core (which is a good thing IMO) is it possible to export zlib functions also, so to reuse code when linking with other software requiring it? I can't really answer that. Would we get the same effect by having Configure probe for a shared libz and Compress::Zlib use that if found? I'm assuming that you'd install a shared libz before building perl for this to work out. Nicholas Clark
Re: problem building latest perl (24978) on win32
В Сбт, 25.06.2005, в 12:19, Nicholas Clark пишет: On Sat, Jun 25, 2005 at 07:59:40PM -0400, vadim wrote: BTW, given that Compress::Zlib is now in the core (which is a good thing IMO) is it possible to export zlib functions also, so to reuse code when linking with other software requiring it? I can't really answer that. Would we get the same effect by having Configure probe for a shared libz and Compress::Zlib use that if found? I'm assuming that you'd install a shared libz before building perl for this to work out. no no no... Compress::Zlib (inside perl distribution) currently includes entire zlib library, and it is certainly should be found. But don't worry, I'll probably check for myself for reusing 'zlib'. Vadim.
Re: perlio_fd_refcnt
In message [EMAIL PROTECTED] (on 25 June 2005 12:05:02 +0200),
[EMAIL PROTECTED] (H.Merijn Brand) wrote:
On Fri, 24 Jun 2005 23:26:56 +0100, Nicholas Clark [EMAIL PROTECTED] wrote:
Would it make sense to replace the hardwired 2048 file descriptor reference
count array (used in perlio.c, defined in perlvars.h)
In in favour of lifting hard coded limits, but I'd not like that to cause
speed concerns. How about a stic set of, say, 32 fd's, and the rest fully
dynamic?
Or the rest allocated 32 at a time?
For the various configurations of perl, are global variables always global
to perl${exe} ? Or can they end up in a shared library and hence have to
stay the same size to maintain binary compatibility?
Good question.
-Allen
--
Allen Smith http://cesario.rutgers.edu/easmith/
There is only one sound argument for democracy, and that is the argument
that it is a crime for any man to hold himself out as better than other men,
and, above all, a most heinous offense for him to prove it. - H. L. Mencken
[PATCH] XSLoader for Sys::Syslog
Hello,
XSLoader is noticeably faster than DynaLoader.
With DynaLoader:
perl -MSys::Syslog -e1 0,26s user 0,02s system 96% cpu 0,289 total
perl -MSys::Syslog -e1 0,28s user 0,00s system 96% cpu 0,292 total
perl -MSys::Syslog -e1 0,28s user 0,00s system 96% cpu 0,291 total
With XSLoader:
perl -MSys::Syslog -e1 0,22s user 0,02s system 98% cpu 0,243 total
perl -MSys::Syslog -e1 0,24s user 0,00s system 96% cpu 0,249 total
perl -MSys::Syslog -e1 0,24s user 0,00s system 97% cpu 0,246 total
--- perl-5.9.3.24982/ext/Sys/Syslog/Syslog.pm- 2005-04-21 00:04:44 +
+++ perl-5.9.3.24982/ext/Sys/Syslog/Syslog.pm 2005-06-26 04:18:56 +
@@ -1,11 +1,10 @@
package Sys::Syslog;
require 5.006;
require Exporter;
-require DynaLoader;
use Carp;
use strict;
-our @ISA = qw(Exporter DynaLoader);
+our @ISA = qw(Exporter);
our @EXPORT = qw(openlog closelog setlogmask syslog);
our @EXPORT_OK = qw(setlogsock);
our $VERSION = '0.06';
@@ -175,7 +174,8 @@ sub AUTOLOAD {
goto $AUTOLOAD;
}
-bootstrap Sys::Syslog $VERSION;
+require XSLoader;
+XSLoader::load('Sys::Syslog', $VERSION);
our $maskpri = LOG_UPTO(LOG_DEBUG);
End of patch
pgpoeC3PnLIlw.pgp
Description: PGP signature
