Julian Foad <julianfoad@btopenworld.com> writes:
> Philip Martin wrote:
>> If using the access baton is wrong, why is using memory allocated
>> by the access baton OK? If using the memory is OK why should I not
>> be able to use the access baton to get it?
>
> Using that memory was not OK in the absence of any interface
> promises regarding it. I should have made a duplicate of that
> string so that it (the duplicate) is definitely not associated with
> the adm_access baton.
The memory remains valid until the pool is cleared, which is perfectly
normal in Subversion. I see no reason for that memory not to be used.
I'm not convinced that imposing non-standard rules on the memory
associated with access batons is a good idea.
>> Can you explain the constraints you are attempting to enforce?
>
> The principle was:
>
> Do not use an adm_access baton after it has been closed.
>
> "Use" means, for example, dereference or pass to another function.
> I think I would now include the path string and any resource that
> was owned by the adm_access baton and not explicitly disowned by it.
Are you planning to poison the entries pointed to be the entries hash?
What about the memory pointed to by the entries themselves? I'd worry
about the impact on performace.
> The reason for trying to enforce that principle (both by trying to
> fix some current violations and by trying to add automatic
> detection) is, of course, that use of any resource after it is
> closed is hard to detect in other ways and is often a source of
> subtle bugs.
Tools like valgrind, and purify will detect attempts to use the memory
after a pool has been cleared. I suspect that attempting to write
your own memory detection stuff is going to be less effective than
those existing tools. Further, any additional problems that your own
system detects will be problems introduced by your new rules.
At present access batons are bound by pool lifetime, just like most
other things in Subversion. Access batons with write locks are a bit
special, because they must prevent attempts to modify the entries file
once the lock file has been removed. The current code already detects
and prevents such modification. Access batons without write locks are
just memory structures, there is not even any guarantee that they
represent the working copy (an access baton with a write lock could
have modified it). As far as I am concerned there is no need to
explicitly close read-only batons, simply abondoning them to pool
cleanup is sufficient.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 9 19:30:51 2003