Re: [MacPerl] What's Latest MacPerl

[Matthew Langford <langfml [at] eng [dot] auburn [dot] edu>]

On Mon, 19 Jul 1999, Richard Gordon wrote:

> Am I correct in believing that your mention of POSIX is purely an 
> illustrative reference (e.g., POSIX doesn't have anything to do with 
> the current MacOS as such)? Also, I understand you to be saying that 
> under both MacOS and Windows, trying to run multiple perl 
> interpreters within the same process essentially doesn't work.

I believe he's saying that MacOS threads are far different from
Unix/POSIX/commonly-understood types of threads, for example they don't
allow thread switching while one is waiting for IO, etc.  They are too
puny to clothe MacPerl effectively, if I can put words in his august
mouth.  :)

I'm probably shouting ignorance here, but I suspect MacOS threads are
mostly designed for OpenTransport-based servers and faceless background
apps.  (FBAs seem to be that subset of programs which are ineffective
enough to stay out of trouble.)

> I've forgotten why, but it seems like I  used to use a clumsy resedit 
> hack to run multiple copies of the same app as separate processes 
> even under System 7. Would this kind of thing make it possible (if 
> not especially practical) to run concurrent scripts that had hacked 
> creator codes to reference correspondingly hacked copies of MacPerl 
> (MacPerl, MacPerl1, MacPerl2, etc.)?

Sure, it works fine.  Or build runtime packages for each tool.  Notice the
massive chunks of memory disappearing.  Complete duplication of resources
(if there isn't, then the possibility of contention for resources is
there).  These are separate processes.

Once again, I'm not speaking with any authority here, but multiple
interpreters inside one process might be like making MacPerl a
multiple-document application.  Like a word processor with multiple open
documents, only MacPerl can be syntax checking one while executing another
and running CPAN and installing modules in yet another.  Perhaps they
could even avoid crashing each other and the whole Mac...Nah!  That's
ridiculous.  ;)

Or a persistent Perl framework which can fork off interpreters to handle
CGI scripts.


--
MattLangford 





===== Want to unsubscribe from this list?
===== Send mail with body "unsubscribe" to macperl-request@macperl.org