[Ns-bugs] [Bug 933] Flushing ostream and files on abnormal program exit (ASSERT, ABORT and FATAL_ERROR)
code@nsnam.ece.gatech.edu
code at nsnam.ece.gatech.edu
Fri Jun 4 07:29:13 PDT 2010
http://www.nsnam.org/bugzilla/show_bug.cgi?id=933
Craig Dowell <craigdo at gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |craigdo at gmail.com
--- Comment #20 from Craig Dowell <craigdo at gmail.com> 2010-06-04 10:29:11 EDT ---
> This does not work from a performance perspective.
What is the real criterion for "does not work from a performance perspective"?
You just ripped out an implementation of pcap file writing that was
significantly faster than the current one, but that worked just fine. What are
the numbers? How are you justifying this comment? How are you justifying all
of this complexity? If you have real numbers showing that packet-by-packet
flushes cause a horrible problem, then use a global variable that one can set
while debugging. How about if I say, "handling stream flushing in an assert
handler does not work from a sofware engineering perspective"? Is that enough
for you?
We are fixing non-bugs with a very complicated scaffolding. If we want to
change the return code on asserts, fine. If we want to flush streams, we
should flush streams just like in the rest of the known universe.
Doing all of this stuff in an assertion handler is, IMO insane. You are now
special-casing a number of "exceptions" like fatal errors and aborts. You
haven't gotten to control-C or other singals or termination with memory leaks
which will have the same effect of not flushing the streams, right? Typically,
users see the flush problem when they have memory leaks.
IMO you are solving a part of the problem in about the most complicated way
possible.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
More information about the Ns-bugs
mailing list