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

Barth Netterfield netterfield at astro.utoronto.ca
Wed Nov 16 04:02:23 CET 2005


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.

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.

cbn


More information about the Kst mailing list