[Kst] [Bug 116461] getdata borks when the first field in the format file isn't (ASCII) alphabetically the first field.
staikos at kde.org
Wed Nov 16 04:10:02 CET 2005
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
> 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
> 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.
KDE Developer http://www.kde.org/
Staikos Computing Services Inc. http://www.staikos.net/
More information about the Kst