On onsdag, juli 24, 2002, at 08:40 , Elizabeth Mattijsen wrote:
>
> At 10:55 AM 7/24/02 -0700, Marc M. Adkins wrote:
>> > etc.... It wouldn't save much, but every little bit helps,
>> > specifically in
>> > a mod_perl environment...
>> This seems to imply that every existing module should have
>> modifications
>> made to make it "well behaved" in a threaded environment.
>
> No, they're usually well-behaved in a threaded environment. I'm
> talking about optimizations here, things that will make it better
> suited for a mod_perl environment with long running processes and
> memory usage issues...
>
>
>> Question: does :unique imply :shared so that these changes require
>> variable
>> locking?
>
> The way I understand it, is that: unique implies "shared, read only
> after cloning".
>
>
>> ... In which case modules should _not_ have these changes made? Oh,
>> wait, does unique even do anything if use threads; hasn't been invoked?
>
> It only has meaning in a threaded environment, i.e. a Perl built with
> thread support, a "use threads" and with threads, other than the main
> thread, actually running.
>
>
>> This is really off the wall...but if Perl has a "constant" mechanism
>> (and it
>> probably does somewhere I don't know about ;) then it might make sense
>> for
>> all constants to automagically be unique.
>
> I don't know too much of the innards, but it appears to me that the
> "unique" mechanism was developed for exactly that purpose, and then
> later given another API with the ": unique" attribute.
>
> (Arthur, please correct me if I'm talking nonsense here... ;-)
>
>
> Liz
>
Yes perl has a constant mechanism
sub foo () { 1} ;-)
print 1;
Currently, that 1 is not shared between threads, constants are not
shared, this is an optimization that should be done.
Arthur
