Christopher Smith wrote:
Darren New wrote:
Christopher Smith wrote:
Tell me how you ensure the destructor runs on an object you
dynamically allocated and forgot to call destroy on?
Object pools, allocators, garbage collectors, etc.
?? C++ doesn't have garbage collectors,
There are entire company's whose existence would contradict that.
Well, yeah, you can do some forms of garbage collection.
> No GC
in the standard, but you most definitely implement GC (indeed, most GC's
are implemented in C or C++, with assembly only being used for
optimization).
Sure. But that's not anything like what we're talking about. Of course
C#'s garbage collector isn't implemented in C#, but in whatever language
the CLR is written in.
and GC doesn't guarantee an object will get finalized, and now you're
telling me you can ensure your destructor runs by using garbage
collectors?
It wouldn't be my first choice, but some C++ GC's have synchronous API's
that block until all objects in the GC'd heap have had their destructors
invoked.
As does C#. How does that help?
So, when a process can no longer log successfully, you'd rather keep
it running than let it die, so it's parent can report the problem and
spawn a new child?!?!
No. When logging throws an exception, the exception gets caught and
logged.
/me just let's the logic of that sink right in. :-)
Depends on whether the exception that's thrown is a condition that's
persistent. If the database you're logging to goes down, you start
logging to the file system until it comes back up, for example.
Of course, if the recovery mechanism dies, then the process exits and I
hear about it. That's pretty rare, tho, and usually indicates a
configuration that's wrong. Indeed, I explicitly do not restart it,
because then I get splammed repeatedly by messages that it died and
restarted, when nothing is going to make it run right.
Since I can reliably work with thrown exceptions, I don't really need to
write code that kills the whole process and restarts it from a different
process. That's usually never needed. Indeed, in the current system,
anything I didn't write gets monitored by that which I did write, and
restarted if it stops being responsive.
A *good* compiler should be able to do escape analysis and realize
that perhaps the object isn't even reachable (which is often the
case) outside of the block.
Agreed. That's another way of doing GC.
It's not quite the same thing, but it can be a helpful tool for
optimizing GC as well. My point is, all compilers fail to warn or
enforce good conventions. It is the nature of the beast.
True.
You're talking about a different kind of system than I am. The service
*does* know.
This some kind of special, relativity violating RPC system? ;-)
Depends on what you mean by "RPC". For example, the optimizer in Hermes
was capable of noticing that service B is always called by service A,
finding all the places that A called B, noticing that the variable in
(say) the second slot of the parameters was always at the same offset,
and compiling in a hard-coded address in B that pointed to A's memory
space, making the invocation more efficient than a straight-forward C
function call would have been. In spite of the semantics of the language
saying that A and B might be running on different machines. It easily
ran multi-user systems distributed over multiple machines with no
memory-mapping or protection hardware. And when one of those machines
crashed, enough extra metainformation was being passed around between
the machines that were communicating that a new machine could pick up
the state and replay the messages and catch up transparently.
So, yeah, the service *does* know.
--
Darren New / San Diego, CA, USA (PST)
It's not feature creep if you put it
at the end and adjust the release date.
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
