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)