Hi Andrew,
you raise a number of valid objections (to using GC and thus, it seems,
Cords), most of whom I cannot readily disprove. I have been reading up
on the details of the Boehm GC and in fact it seems that its
incremental collection scheme relies on virtual memory or else on the
user notifying the GC whenever objects are going to be modified.
Just for the record: there /are/ GCs with hard real-time guarantees. The
problem is that they move life objects around and thus cannot be easily
used for a conservative collector. They also seem to need some sort of
'write barrier' that can only be implemented efficiently with the help
of virtual memory systems. So: no luck for our good old Motorola 68k
boards.
I will try to find out if the basic idea behind cords can be made to
work without a real GC behind it. Maybe using reference counts can be
made to work efficiently in this special case. Also, there seem to be a
number of papers that discuss methods to avoid most or at least some of
the cost of locking reference counters against concurrent access.
However, even if it turns out that we cannot use Cords/Ropes as such for
EPICS V4 (because I fail to come up with an efficient implementation
that doesn't need a real GC), it may /still/ be worthwhile to consider
an interface to strings which does not allow destructive update of an
already constructed string.
Why? Because string data is normally not overwritten at some arbitrary
position. Instead, if the string is modified at all, it either gets
- replaced completely, or else
- new data is incrementally appended
I would bet that 99% of all string modifications follow one of these two
patterns. The first one is typical for dbAccess-type modifications
(including dbPut, dbPutLink) but also inside and in betwen record and
device support. The second one is used mostly when reading from a file;
the string typically ends up being completely constructed and then
stored somewhere, following the first pattern. Thus it seems to me that
a representation in which a string, once it is finally constructed,
cannot be changed any longer, would be quite practical for EPICS. The
remaining few cases that don't follow this pattern can probably be
handled by resorting to ordinary plain char arrays. For this to work
well, we would need /two/ string types: one that allows to append stuff
at the right end, and another one for immutable strings. A problem is
that neither is a subtype of the other, so conversion between the two
must be thought out carefully. I'll try to come up with a concrete
proposal...
Ben
- References:
- V4 EpicsString Benjamin Franksen
- Re: V4 EpicsString Andrew Johnson
- Navigate by Date:
- Prev:
Re: Record support and user-defined fields Benjamin Franksen
- Next:
Re: Record support and user-defined fields Marty Kraimer
- Index:
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: V4 EpicsString Andrew Johnson
- Next:
SNL improvement and ideas Ralph Lange
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|