Experimental Physics and Industrial Control System
> One could argue that the same reasoning applies to all other kinds of
> start-up code that gets executed more or less immediately after IOC
> boot, e.g. in record and device supports init and init_record
> routines.
> An out-of-memory situation here invariably means the IOC is
> overloaded
> and obviously /cannot/ run as the developer planned.
An alternative perspective is that this error handling model can be an
obstacle in the path of implementing on line add and delete capabilities for
the IOC. For example, its probably not great for the IOC to fail if someone
does an online add and we hit a resource consumption limit. Furthermore,
this error handling model is often adopted in order to avoid writing
destructor code, but it seems that database record destructors (clean up
handlers) are definitely needed in the IOC - see mantis 234 (in summary CA's
orderly shutdown isnt currently called for CA links). So after closer
consideration perhaps not much labor can be saved in practice. That (less
effort and or brevity) might have been the original justification for the
fail if we hit a limit error handling model - the callocMustSucceed model.
Jeff
> -----Original Message-----
> From: Benjamin Franksen [mailto:[email protected]]
> Sent: Tuesday, January 31, 2006 3:51 PM
> To: [email protected]
> Subject: Re: mallocMustSucceed( 0 ) non-portable
>
>
> On Tuesday 31 January 2006 21:42, Andrew Johnson wrote:
> > Michael Abbott wrote:
> > >>> Of course this means that callocMustSucceed and
> mallocMustSucceed
> > >>> can return a NULL pointer, which they currently never do.....
> > >>
> > >> That's the dilemma. I thought about that but I believe
> requesting
> > >> zero-sized memory and subsequent de-referencing the return value
> > >> can be considered a programming error. Otherwise, I
> can't see how
> > >> to avoid a memory leak.
> > >
> > > Makes sense to me. After all, what can you legally do with
> > > char * x = malloc(0);
> > > ?
> >
> > I understand that position, however I really don't like it.
> >
> > The ?allocMustSucceed() routines were always a bit of a
> hack to avoid
> > having to check the return value from ?alloc. They are
> only called in
> > dbStaticLib and the IOC startup code in places where if you
> run out of
> > memory there's no way you're going to be able to recover and still
> > bring up the IOC, so the only thing you can do is bail out.
> >
> > They do that by printing an error message and suspending the task,
> > thus ensuring that the caller never gets a chance to continue
> > processing. The task suspend is to allow a developer to do a
> > back-trace on the task that failed and thus find the rogue code, in
> > the event that the problem is being caused by a bug rather
> than a lack
> > of RAM.
>
> One could argue that the same reasoning applies to all other kinds of
> start-up code that gets executed more or less immediately after IOC
> boot, e.g. in record and device supports init and init_record
> routines.
> An out-of-memory situation here invariably means the IOC is
> overloaded
> and obviously /cannot/ run as the developer planned.
>
> Ben
>
- Replies:
- Re: callocMustSucceed error handling model Benjamin Franksen
- References:
- Re: mallocMustSucceed( 0 ) non-portable Benjamin Franksen
- Navigate by Date:
- Prev:
Re: mallocMustSucceed( 0 ) non-portable Benjamin Franksen
- Next:
Hytec 8601 Quad Stepper Motor IP Card - EPICS Driver Available Darrell Nineham
- 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: mallocMustSucceed( 0 ) non-portable Benjamin Franksen
- Next:
Re: callocMustSucceed error handling model Benjamin Franksen
- 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