Subj : Using Prf* routines in window procs
To   : Vitus Jensen
From : David Noon
Date : Tue Jun 20 2000 01:21 pm

Hi Vitus,

Replying to a message of Vitus Jensen to David Noon:

DN>> In general, I do my Prf...() calls in a background thread.

VJ> Feeding it via a pipe or [message] queue, i assume?

Usually I place a request -- either to read a key/application value into a
buffer, or write one from a buffer -- into some memory area shared by the
threads and post a semaphore. The write operation is simply "fire-and-forget".
The read operation does a WinPostMsg() with WM_USER+??? from the background
thread when it is complete. One can invent more exotic schemes to produce
time-out errors, by having the forground thread handle WM_TIMER or WM_USER
messages accordingly, but this is seldom necessary.

VJ> I should have added that I use PrfWriteProfileData to do this dump in
VJ> WM_SAVEAPPLICATION.

Ok.

DN>> The Prf...() routines do cache the .INI file quite aggressively,
DN>> so any application/key/value that has already been read or
DN>> written will almost certainly be accessed again by cache
DN>> lookaside. These API's seem to offer quite an efficient way to
DN>> save and restore an application's settings.

VJ> From the usual discussions about OS2.INI (size and writing strategy) I
VJ> was under the impression that OS/2 holds the complete file in memory.

This is true about OS2.INI and OS2SYS.INI, but that could just be the WPS
reading everything up front. I am not certain about other .INI files. The
application/key values are certainly cached once they've been read and/or
written, and remain cached until the PrfCloseProfile() call, at least in modest
sized files.

VJ> If this were true and PrfOpenProfile is responsible for this caching,
VJ> PrfWriteProfileData would most certainly *not* block (because it only
VJ> has to update the inmemory copy).

This is largely correct. [You can be blocked if you have a page fault that
needs to be resolved from SWAPPER.DAT, but that can happen anywhere.] However,
I have done large copies of application/key pairs from one .INI file to another
and the output file was only accessed when the PrfCloseProfile() call was made;
none of the PrfWriteProfileData() calls caused the copy utility to block. I
cannot be certain that the cache is not limited in size, and once that size is
reached the cache is flushed on, say, a least-recently used basis. If Denis
Tonn were still reading this echo, he would likely have been able to tell us
what limits there are.

So, if there is a size limit your calls _will_ block once you have cached that
much data. If there is no limit they will not block.

VJ> What you told me is that
VJ> 1. PrfWriteProfileData might block (forcing me to keep my design of
VJ> buffering)

Sometimes it _might_ block, but that is seldom.

VJ> 2. PrfReadProfileData will cause some/most of the contents
VJ> to remain in memory (cache)

Correct, but PrfReadProfileData() can block if the application/key pair has not
already been accessed.

VJ> As my design holds a copy of the profile in memory this will double
VJ> the memory requirements.  Stop. :-(

Just use the .INI file's cache instead.

Regards

Dave
<Team PL/I>

--- FleetStreet 1.25.1
* Origin: The man who broke the bank at Monte Carlo (2:257/609.5)