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 --- FleetStreet 1.25.1 * Origin: The man who broke the bank at Monte Carlo (2:257/609.5) .