[Kst] [Bug 116461] getdata borks when the first field in the format file isn't (ASCII) alphabetically the first field.

[George Staikos]

On Tuesday 15 November 2005 22:02, Barth Netterfield wrote:
> On November 15, 2005 06:25 pm, Ted Kisner wrote:
> > Well, this original bug report mentioned something about a race condition
> > when a field in the format file has no data yet.  Is there some reason
> > that getdata doesn't just call getNFrames (which should stat the binary
> > file) for the desired field and if it doesn't exist or has zero size,
> > then return -1 from readField?
> >
> > what am I missing?
>
> Imagine kst accesses a dirfile which is being streamed to in real time
> mode. It wants to plot 100 frames of F1 vs F2.
>
> Imagine that at the moment kst does the accessing, F1 has 1000 frames, and
> F2 has 1001.  If we just use the length of each field, then F1 will be off
> by 1 from F2.  In the next moment they might be aligned again.  This yields
> odd behavior.

  This is exactly the problem they had in Planck too.  It was really a big 
problem.

> So, the rule that we chose was:
> 	The first field in 'format' is always written last, and its length is used
> to define the length of the dirfile.  The length of any other field will be
> ignored.
>
> This generally works pretty well in terms of assuring concurency across the
> dirfile.  This issue is, however, the biggest down side of dirfiles.

  And anything else that writes non-atomically or non-transactionally.

-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/