Subj : Using Prf* routines in window procs
To   : David Noon
From : Vitus Jensen
Date : Wed Jun 07 2000 06:19 pm

Moin David,

04.06.00 18:14, David Noon wrote a message to Vitus Jensen:

 VJ>> Does anybody know whether Prf* routines are usable from inside a
 VJ>> window proc?  Do they block or violate the 1/10s rule in any
 VJ>> other way?

 DN> They block the thread that calls them. The ones that will violate
 DN> the 1/10 second rule are PrfOpenProfile() and PrfCloseProfile(),
 DN> as these will always perform physical I/O. The others might or
 DN> might not perform physical I/O depending on caching of the
 DN> sectors of the .INI file from previous requests.

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

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


 VJ>> Currently I'm using my own Profile routines which are working on
 VJ>> memory structures and dump the new contents to disk whenever
 VJ>> WM_SAVEAPPLICATION is called.  If PrfReadProfileData /
 VJ>> PrfWriteProfileData routines use the same scheme (i.e no file
 VJ>> access) it would double the memory requirements without need.  

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


 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.

From the usual discussions about OS2.INI (size and writing strategy) I was 
under the impression that OS/2 holds the complete file in memory.  If this were 
true and PrfOpenProfile is responsible for this caching, PrfWriteProfileData 
would most certainly *not* block (because it only has to update the inmemory 
copy).

What you told me is that
1. PrfWriteProfileData might block (forcing me to keep my design of buffering)
2. PrfReadProfileData will cause some/most of the contents to remain in memory 
(cache)

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

Bye,
    Vitus

--- Sqed/rexx 2:
 * Origin: 2B OR NOT 2B is the question - FF the answer! (2:2474/424.1)

.