What makes, for example, FSIndexInput and its clones, thread-safe is
the following.
That is, the method is synchronized on the file object.
protected void readInternal(byte[] b, int offset, int len)
throws IOException {
synchronized (file) {
long position = getFilePointer();
if (position != file.position) {
file.seek(position);
file.position = position;
}
int total = 0;
do {
int i = file.read(b, offset+total, len-total);
if (i == -1)
throw new IOException("read past EOF");
file.position += i;
total += i;
} while (total < len);
}
}
On 10/19/06, Chris Hostetter <[EMAIL PROTECTED]> wrote:
: Otherwise, my understanding is that the seek() call before reading
: should put it into a known state, but I am guessing your not so sure on
: that point. So the question is seek() sufficient to put an IndexInput
: into a known safe state, right?
isn't it more subtle then that? ... IndexInput.clone() states that the
clone will be "positioned at the same point as the stream they were cloned
from" ... that implies that the clone will be in a consistent usable state
even with the client calling seek on the clone() .... is that
invarient currently met by BufferedIndexInput in a multithreaded case?
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
