So, Perl assumes POSIX compliance in the OS, eh?

Post #123,335 by jb4 10/29/03 5:13:48 PM Reply	So, Perl assumes POSIX compliance in the OS, eh? Rather presumptious of it, doncha think? jb4 "There are two ways for you to have lower Prescription-drug costs. One is you could hire Rush Limbaugh's housekeeper ... or you can elect me President." John Kerry
Post #123,347 by ben_tilly 10/29/03 5:53:22 PM Reply	No See [link\|http://www.perldoc.com/perl5.8.0/pod/perlfork.html\|perlfork] for how Perl emulates forking on operating systems that don't support it. For a broader introduction to portability and Perl, read [link\|http://www.perldoc.com/perl5.8.0/pod/perlport.html\|perlport]. As usual, Perl's philosophy is to give you enough rope to hang yourself. Perl came from POSIX systems, it offers interfaces to POSIX-specific capabilities. But nobody is saying that you have to use them. And where they don't exist, Perl does its level best to do something reasonable instead. The result is that while it is trivial to write unportable Perl code, nearly all Perl code that you encounter is portable by default to all supported platforms. (Were it not so, then CPAN would never have succeeded.) Supported platforms may be found by scanning the PLATFORMS section of perlport above. Cheers, Ben "good ideas and bad code build communities, the other three combinations do not" - [link\|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html\|Stefano Mazzocchi]
Post #123,463 by jb4 10/30/03 2:06:32 PM Reply	Interesting, but looks like a bit of a kluge The fact that the emulator spawns threads instead of processes means that the desired protection between the fork-ed processes from each other does not exist. I am no Perl guru (hell, I barely know anything about it), but from a design standpoint, this means that any Perl script must be designed to the target platform...and I thought that was counter to what Perl was supposed to be about. (Yeah, Perl does not claim to be Java...but still....) jb4 "There are two ways for you to have lower Prescription-drug costs. One is you could hire Rush Limbaugh's housekeeper ... or you can elect me President." John Kerry
Post #123,472 by ben_tilly 10/30/03 2:48:22 PM Reply	It is a kludge It is meant as a workaround for features that the OS doesn't have. As for protection, the fact that each thread has its own interpreter, and interpreters do not by default share memory, means that most of the protection that you want is there. (The page that I pointed you had describes many of the things that don't get protected.) For the record, that multi-threading model was not intended to be used as a fork() emulation. Rather it was meant to make it possible for Perl to integrate well into IIS, which is multi-threaded. But given that they had the capability, the fork() emulation made sense. On Perl's design. Perl was not intended to be "about" anything. (OK, making easy things easy and difficult things possible...) It was designed as a general-purpose reporting tool for use on Unix, and kind of evolved. In the end Perl turned out to be highly portable, but that wasn't a design goal. Cheers, Ben "good ideas and bad code build communities, the other three combinations do not" - [link\|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html\|Stefano Mazzocchi]
Post #123,473 by deSitter 10/30/03 2:50:47 PM Reply	Re: It is a kludge There are (sigh, were) similar issue with getting things that were born under UNIX to live in the VMS world. -drl
Post #123,486 by ben_tilly 10/30/03 4:22:25 PM Reply	One of those things was Perl ;-) "good ideas and bad code build communities, the other three combinations do not" - [link\|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html\|Stefano Mazzocchi]
Post #123,489 by deSitter 10/30/03 4:36:04 PM Reply	Don't I know! I once downloaded and compiled it on a VAX which had Perl v.low on it :) -drl

Welcome to IWETHEY!