EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: memory management
From: Jeff Hill <[email protected]>
To: 'Benjamin Franksen' <[email protected]>
Cc: 'Eric Norum' <[email protected]>, 'Ralph Lange' <[email protected]>, 'Matej Sekoranja' <[email protected]>, 'Marty Kraimer' <[email protected]>, 'Andrew Johnson' <[email protected]>, 'Ken Evans' <[email protected]>, 'Bob Dalesio' <[email protected]>, "'Kasemir, Kay'" <[email protected]>
Date: Mon, 28 Feb 2005 18:10:01 -0700
> Jeff, could you please explain why the interface of 
> std::string is not 
> compatible with such implementations?
> 

One of the OO convential wisdoms is to never implement an
interface that passes off handles to an internal data structure.
See Item 29 in "Effective C++ 2nd edition", Scott Meyers. To my
continued amazement there is in std::basic_string a function
called c_str() which all implementations I have looked at so far
implement by providing a pointer to the raw internal storage for
the string. Here is the latest GNU source code. This
implementation appears to prevent strings stored in
non-contiguous, fixed sized blocks.

const value_type *c_str( ) const;

      // String operations:
      /**
       *  @brief  Return const pointer to null-terminated
contents.
       *
       *  This is a handle to internal data.  Do not modify or
dire things may
       *  happen.
      */
      const _CharT*
      c_str() const { return _M_data(); }


> BTW, "free-list" is a strange term for allocation in 
> fixed-sized blocks. 
> AFAIK, many different memory allocation schemes keep a list 
> of free memory 
> blocks.

Sorry, this is probably yet another name that has grown to become
universally meaningful to EPICS base persons, but perhaps not in
the wider community.

> 
> > We did experience memory fragmentation issues on vxWorks in
the
> > 90's. I vaguely recall that at the time, after someone had a
> > quick look at the WRS source code, it was stated that the WRS
> > memory allocation algorithms wasn't main stream.
> 
> I've been told things were even worse with the original 
> VxWorks semaphore implementation ;-)
> 

Some of my favorites old WRS bugs...

o crashing every vxWorks when any SUN system booted using bootp
o crashing vxWorks if a person typed "logout" instead of using
"<ctrl>]",
and for some reason they could never log in again!

I dont remember the semaphore bug despite using vxWorks even when
it was still based on the VRTX kernel, but perhaps we jumped over
that version.

Jeff



Replies:
Re: memory management Benjamin Franksen
References:
Re: memory management Benjamin Franksen

Navigate by Date:
Prev: Re: memory management Benjamin Franksen
Next: Re: memory management Benjamin Franksen
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: memory management Benjamin Franksen
Next: Re: memory management Benjamin Franksen
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·