It's been strongly indicated that removing sockets (as well as any
other Perl functions that are little but wrappers around libc calls)
will not meaningfully reduce the size of Perl nor increase its
speed. Various VM issues have been discussed, including risks of
deadly embrace and egregious performance problems resulting from
the running of numerous instantiations on some architectures. A
simple run-once test on a single target platform, or even several,
will not bring these matters to light. but this will all have to
be addressed in exploring what can or cannot be done.
That leaves the deceptively appealing argument that "it will be
easier to port Perl without them". This is trotted out as a strong
argument, but in fact, it is the weakest amongst them. That's
because it is not at *all* true!
Why? Because HAS_SOCKET already takes care of that for sockets.
If the system has them, then they're compiled in. If it doesn't,
then trying to call that function raises an exception at run-time.
You do not make the perl binary more portable by getting rid of
sockets. The build process already considers their availability.
And you do not make Perl scripts more portable, either, because if
sockets aren't available, that socket-diddling script is doomed anyway.
At last check, the following built-in functions in theory can, on
various unfriendly systems, raise "unimplemented" exceptions:
alarm bind chown chroot closedir connect crypt dbmclose dbmopen
fcntl flock fork getgrent getgrgid getgrnam gethostbyaddr
gethostbyname gethostent getlogin getnetbyaddr getnetbyname
getnetent getpeername getpgrp getppid getpriority getprotobyname
getprotobynumber getprotoent getpwent getpwnam getpwuid
getservbyname getservbyport getservent getsockname getsockopt
ioctl kill link listen lstat msgctl msgget msgrcv msgsnd open
opendir pipe readdir readlink readpipe recv rewinddir seekdir
select semctl semget semop send setpgrp setpriority setsockopt
shmctl shmget shmread shmwrite shutdown socket socketpair symlink
syscall telldir times truncate umask utime wait waitpid
There may be other justifications for doing so, but contrary to
popular belief, migrating these functions into modules will *not*
affect the portability of either perl the program or of one's Perl
scripts. So this portability talk should not be used to justify
the act--it's a red herring. The /usr/bin/perl binary itself already
detects and/or emulates the underlying functions at build time, so
it is neither more nor less portable, and the scripts themselves
have little recourse if something critical isn't there. If they
care, they can always test for this either via %Config::Config or,
perhaps, through the old C<eval { syscall }> strategy.
Perhaps something clearer could be devised there, like perhaps
C<exists &CORE::chroot> (or would that be defined?). Seems to me
Nick said something about making all these builtins work just like
real functions, and that should follow. This requires a bit of
-internals work though, more than it does -language work. Well,
unless we wanted
use CORE qw/socket bind connect listen/;
to do the exists() test on all those. I know that I've long wished
for POSIX to, at import time, verify that the things asked for were
actually there, as at this time, it doesn't tell you up front at
compile-time, even with the import, but not till way later upon
calling the function. This, too, will require -internals changes
if it is to be addressed.
--tom
