> "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
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 refere
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
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.
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
> 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 implement. Making them run
> well always requires help from the OS memory manager and that
> would hurt portability. (If we don't have OS
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:
> 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
> 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 curre
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 implemen
> {
> 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 t
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...
> "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 to be
TB> circular by the code that creates them (like a
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 explicit
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 call close.
> Otherwise,
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
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.
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
Damien Neil wrote:
> Using object lifetime to control state is almost never a good idea,
> even if you have deterministic finalization. A much better approach
> is to have methods which allow holders of the object to control it,
> and a finalizer (DESTROY method) which cleans up only if necessary
> 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
On Thu, Feb 15, 2001 at 12:11:27AM +, Simon Cozens 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,
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?
On Wed, Feb 14, 2001 at 05:43:31PM -0300, Branden wrote:
> 4. Why should we bother destroying an object before GC does it?
>
> To free system resources, like open files or database connections. Probably
> the average program won't do it never, but programs that must open several
> files sequentia
[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
On Wed, Feb 14, 2001 at 02:10:59PM -0300, Branden wrote:
>
> Dan Sugalski wrote:
>
> > Plus there's nothing stopping you from having $obj->DESTROY in your own
> > code, though it may be inadvisable.
>
> It is (mainly) inadvisable because:
> 1. GC will call DESTROY when it collects the memory, s
At 07:44 PM 2/14/2001 +, Simon Cozens wrote:
>On Wed, Feb 14, 2001 at 08:32:41PM +0100, [EMAIL PROTECTED] wrote:
> > > DESTROY would get called twice, which is VERY BAD.
> >
> > *blink*
> > It is? Why?
> > I grant you it isn't the clearest way of programming, but "VERY BAD"?
>
>package Nuclear
On Wed, Feb 14, 2001 at 08:32:41PM +0100, [EMAIL PROTECTED] wrote:
> > DESTROY would get called twice, which is VERY BAD.
>
> *blink*
> It is? Why?
> I grant you it isn't the clearest way of programming, but "VERY BAD"?
package NuclearReactor::CoolingRod;
sub new {
Reactor->decrease_core_te
[[ 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 co
[[ reply to this goes only to -internals ]]
Dan Sugalski wrote:
> *) People like it
Well, if people liking it is the only reason (either is the only on or
appears 3 times in a 5 item list, what is pretty much the same to me ;-)
[... the only reason] to add a feature to Perl, we'll probably end
At 07:51 PM 2/12/2001 -0500, Bryan C. Warnock wrote:
>On Monday 12 February 2001 16:54, Dan Sugalski wrote:
> > >Could you guys please use "destruction" or "cleanup" as the term for the
> > >end-of-scope processing (see e.g. C++). Finalization is used everywhere
> > >else to mean: called by GC be
On Monday 12 February 2001 16:54, Dan Sugalski wrote:
> >Could you guys please use "destruction" or "cleanup" as the term for the
> >end-of-scope processing (see e.g. C++). Finalization is used everywhere
> >else to mean: called by GC before the memory is released (see e.g
> >Java/C#).
>
> Corre
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
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 us
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 ma
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 refcount's, since they're storing objects in PMCs. Wha
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 @pr
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 refco
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 attach
[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
>perl variables have no finalization attach
39 matches
Mail list logo
