Re: [MacPerl] What's Latest MacPerl

[Chris Nandor <pudge@pobox.com>]

At 14.47 -0400 1999.07.18, Richard Gordon wrote:
>I would not presume to know exactly how the lack of system level
>support for threads impacts a port of 5.005 to the current MacOS, but
>gather from Rich's post that it is a deal breaker.

You gather wrong.  :)

>A more interesting
>issue is why MacPerl doesn't support threading at the application
>level in any case (at least as far as I know)?

Because it has not yet been implemented.


At 23.09 -0400 1999.07.19, Richard Gordon wrote:
>At 23:09 +0200 07/19/1999, Matthias Neeracher wrote:
>> - The MacOS thread manager was not integrated with the POSIX model of
>>   operation (where you would, at the least, expect blocking file and network
>>   calls to switch threads).
>> - Support for multiple Perl interpreters in the same process used to bve
>>   somewhat flaky, but luckily, that's an area where Windows and MacOS perl
>>   have similar interests.

>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)?

No.  Perl uses POSIX threads, and Matthias is implementing POSIX threads in
his POSIX library (GUSI), and this will eventually allow threading in
MacPerl.


>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'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.

Just make physical copies of the app, and run them.


>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.)?

I run multiple versions of MacPerl all the time.  This is not a very robust
solution, however.

If you are really interested in this kind of thing, macperl-porters
discusses it every once in awhile.  Last month I posted a note about a
discussion I had with Dick Hardt, where he described the plans for an
in-process fork() in Win32 perl.  Basically, if you have threads and
multiplicity, you should be able to use their work to get an in-process
fork().  MacPerl already has multiplicty, and has had it for some time
(this is what allows you to keep the same MacPerl program running and
executing multiple Perl programs without restarting the app).  So when
GUSI2 is done, and MacPerl is updated to the latest perl (merging the
sources with perl proper), MacPerl could get threads, and a fork() for not
much extra work on our (erm, Matthias') part.  At least, that is the hope.

The kicker here is that this work for the in-process fork() is being funded
by Microsoft.  :D

--
Chris Nandor          mailto:pudge@pobox.com         http://pudge.net/
%PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10  1FF77F13 8180B6B6'])

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