Experimental Physics and Industrial Control System
So I also completely agree that assert should never be used in
out-of-resource situations, and if you see such situations in my code I will
be happy to fix them.
>From my perspective the cant-proceed calls are also bad practice in
out-of-resource situations. When there isn't enough resource then we should
nearly always take evasive action. One exception frequently cited is when
starting an IOC its maybe ok, but if this occurs in common library code then
it's probably going to be used inappropriately in other situations, and
surely eventually we will need to upgrade allowing online add and delete of
records and then it's less clear when iocInit starts and ends? Besides, from
an operational perspective, if an IOC is low on memory when it starts
perhaps we are grateful that it continues and somehow against all odds
finishes iocInit continuing to perform limited functions in a degraded mode.
Who knows, perhaps one iocInit started subsystem asks for a huge chunk of
memory - one much bigger than is needed for the ca clients to attach later
(so continuing might actually work)?
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:[email protected]]
> On Behalf Of Dirk Zimoch
> Sent: Wednesday, May 18, 2011 9:35 AM
> To: J. Lewis Muir
> Cc: [email protected]
> Subject: Re: caGateway crashes / use of *MustSucceed functions
>
> J. Lewis Muir wrote:
> > On 5/18/11 7:21 AM, Dirk Zimoch wrote:
> >> Therefore I propose to remove all *MustSucceed functions from
> >> future EPICS releases and allow and require proper error
> >> handling by the application.
> >>
> >> Any opinions on this topic?
> >
> > Hi, Dirk.
> >
> > What about the *MustCreate, *MustWait, and *MustLock functions?
> >
> > epicsEventMustCreate
> > epicsEventMustWait
> > epicsMutexMustCreate
> > epicsMutexMustLock
> > epicsThreadMustCreate
> >
> > On a related note, I didn't look at all of them, but some of
> > these (e.g. epicsEventMustWait) are implemented as macros that
> > just do an assert on the return status of the regular non-must
> > function. Others (e.g. POSIX epicsEventMustCreate) are actual
> > functions, but they too just do an assert. If assertions are
> > disabled, this will do nothing and hence seems broken to me. No?
>
> Hi Lewis,
>
> Yes. This is know as a "Heisenbug" (or the opposite?): bugs that go away
> (or appear) as soon as you switch on debugging. The behavior of the
> program should not change when assertions are switched on.
>
> The idea of assert is to catch situations that "can never happen", as a
> part of the defensive programming paradigm. This may show hidden
> programming errors.
>
> It is not the idea of assert to handle run-time problems like missing
> external resources, e.g. heap memory.
>
> Example: epicsEventMustWait fails if the event id is invalid. This is a
> good application of assert because it should never happen if the program
> is correct.
>
> epicsEventMustCreate fails if the system is out of memory. This is a bad
> application of assert because it may fail due to external influences
> even though the program is correct. However, it would be a good
> application of abort, assuming it is only called during startup. But who
> knows? Better call epicsEventCreate and handle failing resources by
> passing a proper error code back to the caller. Using assert here is
> extremely bad because if assertion is disabled, the error is not handled
> at all and will cause problems later.
>
> Dirk
>
>
- Replies:
- Re: caGateway crashes / use of *MustSucceed functions Dirk Zimoch
- References:
- caGateway crashes / use of *MustSucceed functions Dirk Zimoch
- Re: caGateway crashes / use of *MustSucceed functions J. Lewis Muir
- Re: caGateway crashes / use of *MustSucceed functions Dirk Zimoch
- Navigate by Date:
- Prev:
RE: CA beacon routing error S_errno_ECONNREFUSED Jeff Hill
- Next:
RE: problem with gateway and softIoc running on same server Kevin Tsubota
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
<2011>
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: caGateway crashes / use of *MustSucceed functions Dirk Zimoch
- Next:
Re: caGateway crashes / use of *MustSucceed functions Dirk Zimoch
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
<2011>
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024