summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJarkko Hietaniemi <jhi@iki.fi>2003-09-23 10:04:22 +0000
committerJarkko Hietaniemi <jhi@iki.fi>2003-09-23 10:04:22 +0000
commit425429080f17b5acb37b8d083c12b1c74adbead7 (patch)
tree63a5d030d05020217c8c5da4977709898412da47
parentaf07717d1feb7d2ebd8731ec951eea84cddb5705 (diff)
downloadperl-425429080f17b5acb37b8d083c12b1c74adbead7.tar.gz
Enache Adrian says the FreeBSD malloc example
is no more true. p4raw-id: //depot/maint-5.8/perl@21335
-rw-r--r--pod/perldelta.pod26
1 files changed, 1 insertions, 25 deletions
diff --git a/pod/perldelta.pod b/pod/perldelta.pod
index 7b12713785..b68134fc79 100644
--- a/pod/perldelta.pod
+++ b/pod/perldelta.pod
@@ -472,8 +472,7 @@ This works with both Cygwin 1.3.22 and Cygwin 1.5.3.
In newer FreeBSD releases Perl 5.8.0 compilation failed because of
trying to use F<malloc.h>, which in FreeBSD is just a dummy file, and
-a fatal error to even try to use. Now F<malloc.h> is not used,
-but see L</"FreeBSD: malloc dilemma">.
+a fatal error to even try to use. Now F<malloc.h> is not used.
Perl is now known to build also in Hitachi HI-UXMPP.
@@ -918,29 +917,6 @@ Perl 5.8.1 does build and work well with Cygwin 1.3: with (uname -a)
C<CYGWIN_NT-5.0 ... 1.3.22(0.78/3/2) 2003-03-18 09:20 i686 ...>
a 100% "make test" was achieved with C<Configure -des -Duseithreads>.
-=head2 FreeBSD: malloc dilemma
-
-The choice of malloc (the C-level memory management interface)
-when building Perl is problematic in FreeBSD.
-
-Using FreeBSD's system malloc for Perl was found to be very slow:
-in some cases that was 200 times slower than using the Perl malloc.
-One such case is file input: for example
-
- # slurping the whole compressed Perl source code into $a
- if (open F,"perl-5.8.1.tar.gz") { local $/; $a=<F> }
-
-is about 200-250 times slower with the system malloc than with
-the Perl malloc.
-
-One could use Perl's malloc (Configure -Dusemymalloc), but that
-was found to cause random core dumps in FreeBSD with multithreaded
-programs. No such problems were found in other multithreaded platforms,
-however.
-
-A decision was made to stick with the system malloc, regardless
-of the performance problems.
-
=head2 HP-UX: HP cc warnings about sendfile and sendpath
With certain HP C compiler releases (e.g. B.11.11.02) you will