If you don't do timely destruction, HowMany will return
the wrong value.
Well, no, not really. We'll return the right value, which is the
number of not-dead objects. That the number is surprising to the
programmer is arguably rather sub-optimal but not flat-out
wrong. (Yes, I know I'm arguing twiddly bits here)
The class will have the option of forcing a sweep for dead objects if
it so chooses, so there would be a fallback. Yes, this is definitely
sub-optimal, and is just a variant on the weak-ref problem. (i.e. a
hack of sorts to get around implementation issues)
However, it's not just the semantics you should worry about. Performance might depend on its as well. More than once I've written code where in the DESTROY method a file is closed (and hence, a lock on it is released). If the DESTROY no longer is timely, the semantics won't change - the program would still act correctly.
But the performance would no longer be acceptable, as other programs
don't get their locks fast enough.
I'm not sure that's much of a problem. The delay in destruction
should be on the order of milliseconds under most circumstances. If
that's an unacceptable delay, then odds are something more explicit
than relying on automatic destruction is in order.
You can install block-exit handlers, including in your caller's block, so you don't have to play DESTROY games to get lexical exit actions.
That's nice of newly written perl6 programs. But what about perl5
programs running in a perl6 environment? Or just a perl5 module used
from a perl6 program? Will they have timely DESTROY?
Perl 5 programs won't have as timely a DESTROY as they do running on
the perl 5 engine. Optionally forcing DESTROY checks at block
boundaries will be doable, and I suppose we can optionally force it
at statement boundaries, though that will be slow.
Allocation failure (for example running out of filehandles) will trigger a GC sweep and retry of the failing operation, so your program won't run out of things for lack of timely cleanup.
Could you elaborate on that? If program1 (not necessarely written in
Perl) has an allocation failure because program2 (written in Perl)
hasn't done a GC sweep yet, how's that going to trigger a GC sweep in
program2?
This only applies within a running parrot program of course--we're
not in a position to affect the behaviour of other programs. It's
only when there's a potentially recoverable resource allocation
within a program that we can do this. Locks, for example, can be
tried in non-blocking mode and, if that fails, a GC sweep can be done
and the lock retried in blocking mode to wait on other programs that
might have it allocated. File open failures due to a lack of
filehandles can similarly be tried, a GC run tried, then retried and
only then throwing an exception if there are still no filehandles.
Java's unpredictable GC is already giving lots of people a headache
when dealing with long running Java programs. It would be a pity if
Perl goes that way too.
Could you elaborate on this? There are always tradeoffs when making
choices, and cleaner/faster internals and no worries about circular
garbage is the tradeoff for guaranteed destruction timing. If there
are more serious ramifications, it'd be good to know so we can take
steps to ameliorate them.
-
Are you posting in the right place? Check out Where do I post X? to know for sure.
-
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big>
<blockquote> <br /> <dd>
<dl> <dt> <em> <font>
<h1> <h2> <h3> <h4>
<h5> <h6> <hr /> <i>
<li> <nbsp> <ol> <p>
<small> <strike> <strong>
<sub> <sup> <table>
<td> <th> <tr> <tt>
<u> <ul>
-
Snippets of code should be wrapped in
<code> tags not
<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
intervention).
-
Want more info? How to link
or How to display code and escape characters
are good places to start.
