Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Tue, 1 Feb 2011 15:57:43 -0700

> A discussion on what the epicsEvent routines should do on 
> getting an error from the OS routines is welcome 

This is I think the conventional wisdom on the matter...

o Functions that allocate resources or perform some action such as epicsEventCreate or epicsEventSignal should return an error (or preferably in C++ throw an exception) if they fail. This is consistent with the C runtime library's malloc or scanf for example.

o Functions that de-allocate resources such as epicsEventDestroy print a warning message if they fail, but are not required to return failure status (and certainly in C++ do not throw an exception) if they fail. This is consistent with the C runtime library free for example. In C++ it's always a very bad practice to allow an exception to escape from a destructor.

The primary goal of returning status instead of assert failing when something goes wrong is to allow for recovery from off-normal situations. In C, many codes are challenged in this area of error recovery. In C++ one must code carefully for proper resource recovery when there is an exception, but even in poorly formed codes the odds for successful error recovery do appear to be somewhat higher compared to C. 

Some will say that if something goes wrong we can rarely recover, but from my experience the odds for recovery are actually strong enough to justify some extra code to orchestrate the recovery, and in C++ if we follow some well established coding conventions these benefits come even without substantially increasing the source code size (the object code size probably does increase when properly handling exceptions).

Jeff
______________________________________________________
Jeffrey O. Hill           Email        [email protected]
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

Message content: TSPA

With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead. -- RFC 1925

> -----Original Message-----
> From: [email protected] [mailto:tech-talk-
> [email protected]] On Behalf Of Andrew Johnson
> Sent: Tuesday, February 01, 2011 12:54 PM
> To: EPICS tech-talk
> Subject: Re: epicsEvent (posix implementation) bug ?
> 
> The current Posix implementation of the epicsEvent API contains many uses
> of
> its local checkStatusQuit() macro to detect and handle situations where
> the
> OS' pthread routine returns an error — it prints an error message, then
> calls
> cantProceed() which halts the thread.  In some cases the API leaves
> little
> choice on what /can/ be done, for example the epicsEventSignal() routine
> returns void, so there is no way to signal a fault up to the caller.
> 
> In other cases though we can return an error, and I'm working on changing
> some
> of the internals to just print a warning message and do that instead.
> For
> example, epicsEventCreate() is allowed to return NULL;
> epicsEventMustCreate()
> is provided for users who don't want to handle failures themselves.
> 
> That leaves a few additional cases: epicsEventDestroy() warns but
> continues if
> either of the pthread_xxx_destroy() routines complain, which seems
> sensible
> (it may leak memory, but we have reported something).
> 
> The interesting question (the main purpose of this message) is what to do
> if
> pthread_mutex_unlock() returns an error at the end of the
> epicsEventWait()
> routines.  Currently the code uses checkStatusQuit() so will halt the
> thread,
> unlike the other implementations.
> 
> A discussion on what the epicsEvent routines should do on getting an
> error
> from the OS routines is welcome (but Argonne is about to shut down for a
> 12"+
> snow-storm so don't expect an immediate response from me).
> 
> - Andrew
> --
> If a man is offered a fact which goes against his instincts, he will
> scrutinize it closely, and unless the evidence is overwhelming, he will
> refuse to believe it.  If, on the other hand, he is offered something
> which affords a reason for acting in accordance to his instincts, he
> will accept it even on the slightest evidence.  -- Bertrand Russell

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System