Michel Fortin wrote:
> On 2009-04-19 09:10:12 -0400, Daniel Keep
> said:
>
>> Walter Bright wrote:
>>> Leandro Lucarella wrote:
Close a connection gracefully for example, I guess (I mean, send a
"bye"
packed, not just close the socket abruptly). Same for closing files
writin
On 2009-04-19 09:10:12 -0400, Daniel Keep said:
Walter Bright wrote:
Leandro Lucarella wrote:
Close a connection gracefully for example, I guess (I mean, send a "bye"
packed, not just close the socket abruptly). Same for closing files
writing some mark or something. They can be risky when fin
Personally, I usually use destructors to clean up or to decrement use
counts, bleach secure data, etc. but it should be guaranteed that if
data is no longer allocated, the destructor is called. That may be
elsewhere in the spec, though.
Also, hardware failure should always be expected:
Webse
Christopher Wright, el 18 de abril a las 22:06 me escribiste:
> Walter Bright wrote:
> >Leandro Lucarella wrote:
> >>You missed the point. I'm not talking about freeing the memory. I'm
> >>talking about finalizers. A finalizer could send a "bye" packet throgh the
> >>net. That can't be handled by t
Leandro Lucarella, el 19 de abril a las 13:08 me escribiste:
> Don, el 19 de abril a las 07:35 me escribiste:
> > Leandro Lucarella wrote:
> > >I think shared memory is an example of memory resource that's not freed by
> > >the OS on program exit.
> >
> > Really? That sounds like an OS memory leak
Don, el 19 de abril a las 07:35 me escribiste:
> Leandro Lucarella wrote:
> >I think shared memory is an example of memory resource that's not freed by
> >the OS on program exit.
>
> Really? That sounds like an OS memory leak. Security issue, too: run
> your program, allocated shared memory, then
Unknown W. Brackets, el 18 de abril a las 16:51 me escribiste:
> Well, I guess it would be doable to guarantee destruction, but *only* if
> order of destruction was not guaranteed.
Yes, of course, order *can't* be guaranteed (unless you add read/write
barriers and a lot of overhead at least =)
>
Daniel Keep wrote:
Walter Bright wrote:
Leandro Lucarella wrote:
Close a connection gracefully for example, I guess (I mean, send a "bye"
packed, not just close the socket abruptly). Same for closing files
writing some mark or something. They can be risky when finalization is
not
deterministic
Walter Bright wrote:
> Leandro Lucarella wrote:
>> Close a connection gracefully for example, I guess (I mean, send a "bye"
>> packed, not just close the socket abruptly). Same for closing files
>> writing some mark or something. They can be risky when finalization is
>> not
>> deterministic thou
Don wrote:
[snip]
I think shared memory is an example of memory resource that's not
freed by
the OS on program exit.
Really? That sounds like an OS memory leak. Security issue, too: run
your program, allocated shared memory, then exit. Repeat until all
memory is exhausted.
Run your program
Leandro Lucarella wrote:
Don, el 18 de abril a las 23:43 me escribiste:
I don't understand why D even has finalizers. Can they do anything useful?
Yes. I use them to manage GPU memory/resources. Another are wrapper classes around manually allocated arrays (to avoid the false pointer problem with
Walter Bright wrote:
Leandro Lucarella wrote:
You missed the point. I'm not talking about freeing the memory. I'm
talking about finalizers. A finalizer could send a "bye" packet throgh
the
net. That can't be handled by the OS.
That shouldn't be handled by a finalizer. A "bye" packet can be h
Leandro Lucarella wrote:
You missed the point. I'm not talking about freeing the memory. I'm
talking about finalizers. A finalizer could send a "bye" packet throgh the
net. That can't be handled by the OS.
That shouldn't be handled by a finalizer. A "bye" packet can be handled
by a static dest
Walter Bright Wrote:
> Leandro Lucarella wrote:
> > Close a connection gracefully for example, I guess (I mean, send a "bye"
> > packed, not just close the socket abruptly). Same for closing files
> > writing some mark or something. They can be risky when finalization is not
> > deterministic thou
Well, I guess it would be doable to guarantee destruction, but *only* if
order of destruction was not guaranteed.
In other words, at the end, the GC would not scan, it would just
destroy. Scanning is a problem, due to cycles and various other things,
but destroying all roots would be potentia
Unknown W. Brackets, el 18 de abril a las 16:16 me escribiste:
> The simple solution is this:
>
> 1. If your class object only involves memory, freed OS handles, etc., it
> should be used as-is. This is most class objects. Destructors are
> needed to clamp resource use (see File class.)
A File
The simple solution is this:
1. If your class object only involves memory, freed OS handles, etc., it
should be used as-is. This is most class objects. Destructors are
needed to clamp resource use (see File class.)
2. If your class object involves hardware handles, transactional
assurance,
Leandro Lucarella, el 18 de abril a las 19:36 me escribiste:
> Rainer Deyke, el 18 de abril a las 16:18 me escribiste:
> > Leandro Lucarella wrote:
> > > You missed the point. I'm not talking about freeing the memory. I'm
> > > talking about finalizers. A finalizer could send a "bye" packet throgh
Rainer Deyke, el 18 de abril a las 16:18 me escribiste:
> Leandro Lucarella wrote:
> > You missed the point. I'm not talking about freeing the memory. I'm
> > talking about finalizers. A finalizer could send a "bye" packet throgh the
> > net. That can't be handled by the OS.
>
> It can't be handle
Don, el 18 de abril a las 23:43 me escribiste:
> >>I don't understand why D even has finalizers. Can they do anything useful?
> >Yes. I use them to manage GPU memory/resources. Another are wrapper classes
> >around manually allocated arrays (to avoid the false pointer problem with
> >very
> >lar
Fawzi Mohamed, el 18 de abril a las 23:41 me escribiste:
> >>when the main thread ends other threads might be running, and removing
> >>memory they are using is not necessarily a good idea.
> >Then I guess gc_term() should be invoked when all threads have terminated.
> >Is there any technical diffi
Leandro Lucarella wrote:
> You missed the point. I'm not talking about freeing the memory. I'm
> talking about finalizers. A finalizer could send a "bye" packet throgh the
> net. That can't be handled by the OS.
It can't be handled by the GC either, because:
- This would require a high-level wra
Fawzi Mohamed, el 18 de abril a las 23:43 me escribiste:
> >If thread_joinAll() is called before gc_term(), I can't see how a thread
> >could be still running when gc_term() is called. So, in terms of threads,
> >I don't see a problem here.
>
> daemon theads are not joined
So, you can keep thread
Walter Bright, el 18 de abril a las 14:34 me escribiste:
> Leandro Lucarella wrote:
> >Close a connection gracefully for example, I guess (I mean, send a "bye"
> >packed, not just close the socket abruptly). Same for closing files
> >writing some mark or something. They can be risky when finalizati
Walter Bright, el 18 de abril a las 14:33 me escribiste:
> Leandro Lucarella wrote:
> >The current GC implementation don't call finalizers for data that's still
> >reference when the program *ended* (this is allowed by the specs, so it's
> >fine, the question is why it's allowed by the specs).
>
>
Robert Jacques wrote:
On Sat, 18 Apr 2009 16:25:32 -0400, Don wrote:
Leandro Lucarella wrote:
Robert Jacques, el 18 de abril a las 11:56 me escribiste:
On Sat, 18 Apr 2009 11:24:14 -0400, Leandro Lucarella
wrote:
I've just found out[1] this[2]:
The garbage collector is not guaranteed
On 2009-04-18 23:22:21 +0200, Leandro Lucarella said:
Leandro Lucarella, el 18 de abril a las 18:03 me escribiste:
Fawzi Mohamed, el 18 de abril a las 22:48 me escribiste:
On 2009-04-18 22:25:32 +0200, Don said:
Leandro Lucarella wrote:
Robert Jacques, el 18 de abril a las 11:56 me escrib
On 2009-04-18 23:03:11 +0200, Leandro Lucarella said:
Fawzi Mohamed, el 18 de abril a las 22:48 me escribiste:
On 2009-04-18 22:25:32 +0200, Don said:
Leandro Lucarella wrote:
Robert Jacques, el 18 de abril a las 11:56 me escribiste:
On Sat, 18 Apr 2009 11:24:14 -0400, Leandro Lucarella
Leandro Lucarella wrote:
Close a connection gracefully for example, I guess (I mean, send a "bye"
packed, not just close the socket abruptly). Same for closing files
writing some mark or something. They can be risky when finalization is not
deterministic though.
Scoped objects should be used fo
Leandro Lucarella wrote:
The current GC implementation don't call finalizers for data that's still
reference when the program *ended* (this is allowed by the specs, so it's
fine, the question is why it's allowed by the specs).
The why is because of speed. What's the point of running a gc pause
Leandro Lucarella, el 18 de abril a las 18:03 me escribiste:
> Fawzi Mohamed, el 18 de abril a las 22:48 me escribiste:
> > On 2009-04-18 22:25:32 +0200, Don said:
> >
> > >Leandro Lucarella wrote:
> > >>Robert Jacques, el 18 de abril a las 11:56 me escribiste:
> > >>>On Sat, 18 Apr 2009 11:24:14
On Sat, 18 Apr 2009 16:25:32 -0400, Don wrote:
Leandro Lucarella wrote:
Robert Jacques, el 18 de abril a las 11:56 me escribiste:
On Sat, 18 Apr 2009 11:24:14 -0400, Leandro Lucarella
wrote:
I've just found out[1] this[2]:
The garbage collector is not guaranteed to run the destruc
Fawzi Mohamed, el 18 de abril a las 22:48 me escribiste:
> On 2009-04-18 22:25:32 +0200, Don said:
>
> >Leandro Lucarella wrote:
> >>Robert Jacques, el 18 de abril a las 11:56 me escribiste:
> >>>On Sat, 18 Apr 2009 11:24:14 -0400, Leandro Lucarella
> >>>wrote:
> I've just found out[1] this
On 2009-04-18 22:25:32 +0200, Don said:
Leandro Lucarella wrote:
Robert Jacques, el 18 de abril a las 11:56 me escribiste:
On Sat, 18 Apr 2009 11:24:14 -0400, Leandro Lucarella wrote:
I've just found out[1] this[2]:
The garbage collector is not guaranteed to run the destructor for
Don, el 18 de abril a las 22:25 me escribiste:
> >The current GC implementation don't call finalizers for data that's still
> >reference when the program *ended* (this is allowed by the specs, so it's
> >fine, the question is why it's allowed by the specs).
>
> I don't understand why D even has fi
Leandro Lucarella wrote:
Robert Jacques, el 18 de abril a las 11:56 me escribiste:
On Sat, 18 Apr 2009 11:24:14 -0400, Leandro Lucarella wrote:
I've just found out[1] this[2]:
The garbage collector is not guaranteed to run the destructor for
all unreferenced objects.
Is there
Robert Jacques, el 18 de abril a las 11:56 me escribiste:
> On Sat, 18 Apr 2009 11:24:14 -0400, Leandro Lucarella
> wrote:
> >I've just found out[1] this[2]:
> >
> > The garbage collector is not guaranteed to run the destructor for
> > all unreferenced objects.
> >
> >Is there any reason
On Sat, 18 Apr 2009 11:24:14 -0400, Leandro Lucarella
wrote:
I've just found out[1] this[2]:
The garbage collector is not guaranteed to run the destructor for
all unreferenced objects.
Is there any reason why D can't guarantee that all finalizers will be
called, at least when
I've just found out[1] this[2]:
The garbage collector is not guaranteed to run the destructor for
all unreferenced objects.
Is there any reason why D can't guarantee that all finalizers will be
called, at least when the program ends?
[1] http://proj.llucax.com.ar/blog/dgc/blog/po
39 matches
Mail list logo
