Sorry guys, Im afraid I STILL havent done a real read-through the last few posts. But I will!

I'm busy fighting my file-reader coding ATM. Pointer issues... no surprise! Im NOT looking for help on that though, cause I need to
get back up-to-speed with pointers anyway, and I'll get there soon enough. Then I'll get back on track with my thread testing.

But in the meantime, as an off-topic (hey! Its MY thread, I can do it!), can anyone answer these API questions?

1> The "FileCreate" in my sample code is causing a noticable 'lag' when FIRST opening the file in question. This makes me suspect that
the WHOLE file is being cached somewhere. Is my suspicion correct?

2> Is this file being cached INSIDE the acknex workspace, or is it being cached by the OS somewhere outside? ( my diagnostic attemps were inconclusive)

3> Is there any way to prevent the cacheing, or to limit the size of the 'chunk' being cached? (for this ONE file, and from within API)

For these questions, I need to TRY and keep with OpenFile for its ability to allow control of the internal file pointer when retrieving data.

Thanks guys.


PS: Damn, this off-topic nearly deserves its own thread, but we'll see how it goes. Maybe later.

Off-Topic:

1> No, not the WHOLE file.

2> It is cached on the far heap (INSIDE your application).

3> Yes, but not with "CreateFile", (as far I know).

>>For these questions, I need to TRY and keep with OpenFile for its ability to allow control of the internal file pointer when retrieving data.
What???

OK, Im finally back.
I was doing a rebuild of my work-pc (where I do my lite-c work),
and it went horribly wrong when I connected to the network...

Bunsen:
1> It must just be cacheing either a large chunk, or it is the
OS trying to 'find' the file. (deep path ATM)

2> Then do you know if the default.c diag panel shows this memory usage?
I couldnt see any change...

3> I have since discovered CreateFile CAN read non-buffered, but it gets ugly.
You need your own buffer/chunksize to match the HDD clustersize(simplified description)

>> If I open the file using CreateFile, I can move the 'readfrom' position manually using the 'SetFilePointer' API.
That way I could openfile, read a bit, skip a bit, read a bit, etc, close. NEVER going backwards.

BUT, since then, Ive decided I want to use a zip-library in my app to reduce the file-size.
Buffering becomes a necessity then, so Ive dropped the whole no-buffer idea completely.

OK everyone, this thread is now actually, RESOLVED, but I cant update the thread heading anymore.

Iv looked at eryones stuff (to varying degrees) and appreciate all your input,
every little bit helped.

I have ended up going in the following directions...

1> The vertex-displacement thread has been abandoned and merged into the buffering function.
ent_getvertex was too unreliable in a thread, and syncronising the thread not worth the effort.

2> The datafile-read thread is working nicely without a 'standard' mutex system.
I am using a pointer shared between both threads as a mutex, and a shared flag to terminate all threads.
I can post the code if someone wants, I just dont have that usb-stick installed ATM...


Thanks all for your inputs...