Re: a slightly updated rpm spec file for Ger Hobbelt crm114 branch

   From: =?ISO-8859-15?Q?Jaakko_Hyv=E4tti?= <[email protected]>

   On Mon, 2 Feb 2009, Bill Yerazunis wrote:
   > What happens when you hit a CRM_ASSERT?  With no I/O, your
   > embedded device hangs.

   It should, because if the C coder has allowed a function to be called with 
   invalid input, you do not know if there is ANY script there to return to 
   or if the memory is corrupted and you are going to inject fuel to a coffee 
   cup next. It is safest to HALT. A watchdog will reboot if necessary.

Maybe.  But consider the situation where you're connected to 
an SQL database or other (stateful) system.  You're doing a
table update, and you have the table locked for what should be
a relatively short transaction.  You hang.  You watchdog reboot.

Your side of the transaction handle is gone with the reboot.  But
the SQL database is waiting for it.  Waiting till _it_ times out,
and rejects the transaction.  In the meantime, all of those 
records are stuck.  

This will make you exceedinly unpopular with the DBA people and 
with the PHBs who are your mutual managers.

As they say on Mythbusters, "I reject your reality and substitute my
own".  The _right_ thing to do here is for the classifier to
detect the error, return an error code (which is fast to test) and
an explanatory string (for the humans, should there be any who care),
free() up anything malloc()d, clean up anthing else that needs cleaning,
and _gracefully return_.  

A sorta-right thing to do is for the classifier to return a wrong answer,
clean up, and gracefully return.  Remember, these are probabalistic
methods we're using here; getting it right 99.99% of the time _is_
cause for celebration.  So, a wrong answer is not necessarily
bad, it will happen even with perfect code.

   This is why for example linux kernel does not just return error but 
   halts when some assertions fail.

It errors, logs the error, and tries a lot of fixups first.  

   Ger's mail sure is a complete answer to this, just wanted to 'vote'.

No, it's not.  I know of no stdio routine that will _kill your
process_ if a file isn't found, isn't writeable, the disk is out of
space, the arguments didn't match the calling sequence, etc.  The
right response is "clean up and return an error code".

"Log it and die" may be OK for a toplevel process, but it's the
wrong response for anything in a library.

      - Bill Yerazunis


------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com