John Marshall <[EMAIL PROTECTED]> wrote:
> if (DmResizeRecord != NULL) {
> DmGetRecord
> MemHandleLock | These three lines needed only if you
> DmWrite | actually want to write something to
> MemHandleUnlock | the record
> DmReleaseRecord (..., true)
> }
...which has a race condition. If the app were to die after DmResizeRecord
but before DmGetRecord, you would have a non-busy non-dirty record which
has been changed, so ought to be dirty. Not that this is likely to be a
problem in practice.
> DmResizeRecord doesn't set the dirty bit, but (unless newsize == oldsize)
> it does change the contents of the record, so it seems as if it should.
Or another way to look at it would be to consider that DmResizeRecord,
like DmWrite, requires a writable handle to the record. This seems to
match the reality of the thing. It's a bit misleading that DmResizeRecord
takes an index parameter -- it would be more explicit if it needed you to
pass in the handle -- but there you go.
So the really-correct-this-time flow would be (theoretically -- I haven't
tested this):
DmQueryRecord(i)
if (we_want_to_resize_the_record()) {
h = DmGetRecord(i)
h = DmResizeRecord(i /*h*/) /* Need to resample h */
MemHandleLock(h)
DmWrite
MemHandleUnlock
DmReleaseRecord(i)
}
...which I think is probably what Danny was describing in his last email,
and which doesn't suffer from the "conceivably leaves a non-busy record in
an invalid state" problem that my code above does. Not that that would
ever happen...
Stephen Best <[EMAIL PROTECTED]> wrote:
> Yet another alternative is for DmResizeRecord itself to set the busy bit. In
> essence it's not substantially different from DmGetRecord (in that both
> return a handle). IMHO, this is the logical thing to do.
Possibly, except that would multiply the number of ways to conjure up a
writable handle to a record, which would confuse me even further. :-)
And of course that would be an incompatible change between OS versions...
It looks like thinking of DmResizeRecord as modifying an *existing*
writable handle, rather than returning a new one, is the right way to go.
John "hopefully this public blithering helped someone besides me"
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
