On Thu, Feb 15, 2001 at 02:26:10PM -0500, Uri Guttman wrote:
"TB" == Tim Bunce [EMAIL PROTECTED] writes:
TB As a part of that the weak reference concept, bolted recently into
TB perl5, could be made more central in perl6.
TB Around 92.769% of the time circular references are known
"TB" == Tim Bunce [EMAIL PROTECTED] writes:
TB On Thu, Feb 15, 2001 at 02:26:10PM -0500, Uri Guttman wrote:
"TB" == Tim Bunce [EMAIL PROTECTED] writes:
TB As a part of that the weak reference concept, bolted recently into
TB perl5, could be made more central in perl6.
TB
Hong Zhang
A deterministic finalization means we shouldn't need to force
programmers
to have good ideas. Make it easy, remember? :)
I don't believe such an algorithm exists, unless you stick with reference
count.
Either doesn't exist, or is more expensive than refcounting. I guess we
On Thu, Feb 15, 2001 at 08:21:03AM -0300, Branden wrote:
Hong Zhang
A deterministic finalization means we shouldn't need to force
programmers
to have good ideas. Make it easy, remember? :)
I don't believe such an algorithm exists, unless you stick with reference
count.
Either
Tim Bunce wrote:
On Thu, Feb 15, 2001 at 08:21:03AM -0300, Branden wrote:
And don't forget that if we stick with refcounting, we should try to
find a
way to break circular references, too.
As a part of that the weak reference concept, bolted recently into perl5,
could be made more central
Damien Neil wrote:
On Thu, Feb 15, 2001 at 08:07:39AM -0300, Branden wrote:
I think you just said all about why we shouldn't bother giving objects
deterministic finalization, and I agree with you. If we explicitly want
to
free resources (files, database connections), then we explicitly
Branden wrote:
Just set autoflush, if you're lazy...
And say goodbye to performance...
The problem is
that you can not only count on $fh's DESTROY being called at the end of
the block, you often can't count on it ever happening.
Anyway, the file would be flushed and closed...
That's
{
my $fh = IO::File-new("file");
print $fh "foo\n";
}
{
my $fh = IO::File-new("file");
print $fh "bar\n";
}
At present "file" will contain "foo\nbar\n". Without DF it could just
as well be "bar\nfoo\n". Make no mistake, this is a major change to the
Hong Zhang wrote:
This code should NEVER work, period. People will just ask for trouble
with this kind of code.
Actually I meant to have specified "" as the mode, i.e. append, then
what I originally said holds true. This behaviour is predictable and
dependable in the current perl
Hong Zhang wrote:
This code should NEVER work, period. People will just ask for trouble
with this kind of code.
Actually I meant to have specified "" as the mode, i.e. append, then
what I originally said holds true. This behaviour is predictable and
dependable in the current perl
Hong Zhang wrote:
That was not what I meant. Your code already assume the existence of
reference counting. It does not work well with any other kind of garbage
collection. If you translate the same code into C without putting in
the close(), the code will not work at all.
Wrong, it does
Alan Burlison wrote:
I think you'll find that both GC *and* reference counting scheme will
require the heay use of mutexes in a MT program.
There are several concurrent GC algorithms that don't use
mutexes -- but they usually depend on read or write barriers
which may be really hard for us to
Hong Zhang wrote:
The memory barriers are always needed on SMP, whatever algorithm
we are using.
I was just pointing out that barriers are an alternative to mutexes.
Ref count certainly would use mutexes instead of barriers.
The memory barrier can be easily coded in assembly, or intrinsic
At 02:08 PM 2/15/2001 -0800, Hong Zhang wrote:
Hong Zhang wrote:
This code should NEVER work, period. People will just ask for trouble
with this kind of code.
Actually I meant to have specified "" as the mode, i.e. append, then
what I originally said holds true. This behaviour is
At 09:13 PM 2/15/2001 -0500, Ken Fox wrote:
Hong Zhang wrote:
The memory barriers are always needed on SMP, whatever algorithm
we are using.
I was just pointing out that barriers are an alternative to mutexes.
Ref count certainly would use mutexes instead of barriers.
Not really they
[[ reply goes to -internals ]]
OK. Let's clear it up all at once from start. Below is the lifecycle of an
object (in Perl). A reference is blessed, and an object is the result of
this blessing. During the object's life, several methods of it are called,
but independent of which are called, it
[trimming distribution to -internals only]
On Wed, Feb 14, 2001 at 07:44:53PM +, Simon Cozens wrote:
package NuclearReactor::CoolingRod;
sub new {
Reactor-decrease_core_temperature();
bless {}, shift
}
sub DESTROY {
Reactor-increase_core_temperature();
}
A better
On Wed, Feb 14, 2001 at 01:24:34PM -0800, Damien Neil wrote:
Using object lifetime to control state is almost never a good idea,
even if you have deterministic finalization.
A deterministic finalization means we shouldn't need to force programmers
to have good ideas. Make it easy, remember?
A deterministic finalization means we shouldn't need to force programmers
to have good ideas. Make it easy, remember? :)
I don't believe such an algorithm exists, unless you stick with reference
count.
Hong
Jan Dubois wrote:
On Mon, 12 Feb 2001 01:44:54 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
Perl needs some level of tracking for objects with finalization attached
to
them. Full refcounting isn't required, however. Also, the vast majority
of
perl variables have no finalization attached to
At 01:45 PM 02-12-2001 -0300, Branden wrote:
I think having both copying-GC and refcounting-GC is a good idea. I may be
saying a stupid thing, since I'm not a GC expert, but I think objects that
rely on having their destructors called the soonest possible for resource
cleanup could use a
Buddha Buck wrote:
At 01:45 PM 02-12-2001 -0300, Branden wrote:
Am I too wrong here?
It's... complicated...
Agreed.
Here's an example of where things could go wrong:
sub foo {
my $destroyme1 = new SomeClass;
my $destroyme2 = new SomeClass;
my @processme1;
At 11:01 PM 2/11/2001 -0800, Jan Dubois wrote:
[moved to -internals]
On Mon, 12 Feb 2001 01:44:54 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
Perl needs some level of tracking for objects with finalization attached to
them. Full refcounting isn't required, however. Also, the vast majority of
At 09:49 AM 2/12/2001 -0800, Jan Dubois wrote:
On Mon, 12 Feb 2001 14:50:44 -0300, "Branden" [EMAIL PROTECTED]
wrote:
Actually I was thinking something like PMCs ($@%) being copy-GCed and
referred objects (new SomeClass) being refcounted. In this case above, every
operation would use
At 10:46 AM 2/12/2001 -0800, Jan Dubois wrote:
On Mon, 12 Feb 2001 13:29:21 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
At 10:38 AM 2/12/2001 -0500, Sam Tregar wrote:
On Mon, 12 Feb 2001, Dan Sugalski wrote:
Perl needs some level of tracking for objects with finalization
attached to
25 matches
Mail list logo
