> Jupiterhost.Net wrote:
> 
> >
> >> Ok, well you think that might have helped to state in the first place,
> >> especially when posting to a beginners list?
> > 
> > Sorry I didn't mean to offend anyone, I felt it was irrelevant to the
> > question. (IE - How do I vacuum my car instead of How would I vacuum a
> > blue car?)
> > 
> 
> no need to apologize, you didn't offend anyone. i read the thread and i 
> agree with you that your question of how to undef a ref is irrelevant to 
> how you manage a persistent process via PersistentPerl or FCGI or mPerl.
>

I still disagree.  If for no other reason than the original post would
be very confusing to the beginners who look through the archive (if such
a person exists ;-)), then ask why their variables don't persist across
separate calls to Perl.  "Offend" is probably a bit harsh, but it
certainly would have been easier/faster to state "When working with
PersistentPerl, I would like to do...." because about half the time on
this list the OP is asking a question that may relate to *their*
implementation but the eventual outcome is a re-analysis of how they got
to their question to begin with.
 
> >
> > I simply was trying to figure out the best way to undef/close/other wise
> > destroy each ref in a list of refs depending on the type of reference. I
> > figured the way I was doing it didn't matter because either way all I
> > want to do is:
> > 
> > undef ${$_} if ref($_) eq 'SCALAR';
> > I can do the above for SCALAR, ARRAY, HASH
> > but the question is what do I do if it's one of these:
> >   IO, GLOB, or CODE
> >
> 
> no need to do that, you don't want to undef what $_ points to, you
want to 
> undef $_ itself. for example:
> 

But isn't that the point, that he *does* want to undef what it points
to?  Which is why I suggested looking at the scoping issues and
attempted to establish the smallest loop of execution which leads
directly into the discussion of how his variables were persisting...etc.

> #!/usr/bin/perl -w
> use strict;
> 
> $_ = {a => b => c => 1};
> 
> undef %{$_};
> 
> print "still a ref\n" if ref $_;
> 
> __END__
> 
> prints:
> 
> still a ref
> 
> simply:
> 
> * undef $_ is fine
> * in fact, you can loose a reference count (Perl uses reference
counting to 
> gc) by simply pointing $_ to somewhere like:
> 
> $_ = 1;
>

But that is assuming there is only one reference to whatever $_ points
to, it has to be the *last* reference.
 
Two cases I can think of right away, where simply undef'ing the contents
of the variable that the reference points too won't work... filehandles
that have not been flushed, and objects who have a DESTROY method.  Both
of these are special actions taken when a referent is garbage collected,
simply resetting its value won't take the proper precautions.

There is *a lot* that would need to be checked when using PersistentPerl
especially with any non-home grown modules, similar to checking for
Thread safety or concurrency issues.  

It would seem it is still safer to have Perl handle the garbage
collection by mangling the reference counts, possibly through contrived
scoping.  Regardless, the code better be *thoroughly* tested...

http://danconia.org

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>


Reply via email to