>Lucy24@... wrote:
>
>> At one time or another, every person in the know has told me that
>>   CALL RELEASERESOURCE
>> is unnecessary--mark it purgeable & the memory manager will do the rest. But
>> here's the weird part: if I cut this statement and make _no other changes_
>> (this is not one of those "change six things and then tear out your hair
>> trying to figure out which of the six is preventing things from working
>> properly" situations)... the resource will then do the _opposite_ of what I
>> expect, especially at program startup. That is, a string might display
>> incorrectly, or a PICT will vanish from the screen. Again, that's if I
>>_don't_
>> RELEASERESOURCE.
>
>I for one do _not_ consider RELEASERESOURCE to be unnecessary, in spite
>of what "every person in the know" may say to the contrary.  Releasing
>resources and purging resources are two different things which serve two
>different purposes and, most importantly, have different kinds of
>effects on your program.  A purged resource is simply not treated the
>same way by the OS as a released resource is.
>
>Here is an example of how removing a RELEASERESOURCE call might mess up
>your program.  I don't know how similar these scenarios are to your
>situation, but it illustrates my point.
>
>Let's say you have a "PICT" resource #3000 which is purgeable, and you
>use it under each of the following situations:
>
>Scenario 1: "with"
>------------------
>1. You get a handle to the resource: h& = FN GET1RESOURCE(_"PICT", 3000)
>2. During the course of subsequent processing, the resource happens
>   to get purged.  But the Resource Manager _remembers_ the handle
>   (this is one big difference between purging and "Releasing").
>3. You CALL RELEASERESOURCE(h&).  The memory block was already
>   released in Step 2, but now we are also telling the Resource
>   Manager to forget about the _handle_ as well.
>4. Some time later, you call h& = FN GET1RESOURCE(_"PICT", 3000)
>   again.  The Resource Manager allocates a new memory block (with
>   a brand new handle), loads the resource into it, and returns the
>   block's handle to your program.  h& is now a valid handle to
>   real data, and everything's rosy.
>
>Scenario 2: "without"
>---------------------
>1. You get a handle to the resource: h& = FN GET1RESOURCE(_"PICT", 3000)
>2. During the course of subsequent processing, the resource happens
>   to get purged.  But the Resource Manager _remembers_ the handle.
>3. This time, you do NOT call RELEASERESOURCE.  You've commented
>   it out of your code.
>4. Some time later, you call h& = FN GET1RESOURCE(_"PICT", 3000)
>   again.  The Resource Manager looks in its resource map and
>   says "ah!  I already have a handle that's associated with that
>   resource," and it returns that handle to your program.  The
>   problem is, it's a handle to a non-existent block.  The Resource
>   Manager does _not_ allocate a new block, and does _not_ load
>   the resource back into memory for you.  It just returns the
>   old handle.  If you now call some routine that assumes there's
>   an actual block of data associated with that handle, then you're
>   _lucky_ if you merely get unexpected program behavior.  More
>   likely, you'll crash.
>
>Because of "gotcha's" like this, I usually find my programming to be
>simplified by using NON-purgeable resources.  When they're purgeable,
>you need to do extra steps to make sure they're really in memory when
>you expect them to be.
>
>Yes, you can always call HNOPURGE after you load them; but then what's
>the point of making them purgeable in the first place?
>
>Yes, you can always call HPURGE again once you're finished using them;
>but why not just replace that HPURGE call with a RELEASERESOURCE call?
>That way you free up the memory immediately instead of at some
>unspecified time in the future, and you eliminate problems associated
>with the "dangling handle" such as the one illustrated in Scenario 2
>above.
>
>Yes, you can use purgeability as a sort of "poor man's garbage
>collection" if you prefer to be relieved of the responsibility of
>calling RELEASERESOURCE all the time.  But purgeable resources impose
>_other_ responsibilities on your coding that non-purgeable resources
>don't.  In my own case, I don't find the tradeoff to be worth it.
>
>In my opinion, the time to use a purgeable resource is when you want to
>allow the Memory Manager to reclaim memory, but you specifically do
>_not_ want the resource's old _handle_ to go away.  For example, you may
>have a number of copies of the resource's handle in a number of
>different long int variables, and you may want to (reload and) use that
>resource again later but you don't want to have to go alter all those
>variables when you do.  The Resource Manager _maintains_ the handle's
>association with the resource when it's _purged_; the Resource Manager
>_destroys_ the handle's association with the resource when it's
>_released_.  That distinction is important to remember when you're
>deciding whether to use purgeable resources, because the difference can
>affect the behavior of your program.
>
>- Rick
>
>--
>To unsubscribe, send ANY message to <futurebasic-unsubscribe@...>


Alessandro

It often happens that what I write in English isn't what I really think in
Italian... what I write in Italian isn't what I really think in
Italian....what I compile isn't what I think at all...