> On Mon, 2002-09-02 at 02:45, Gerald Richter wrote:
> > I hope this make things more clear, if not just ask again. If I am
overseen
> > something here and there is a better way to do these things I am happy
to
> > learn...
>
> Perhaps a hash table mapping the dav_resource pointer to the perl
> object? You'd need some way of cleaning that up when a dav_resource
> structure is freed (or rather, when its containing pool is freed), but I
> think you'd need that anyway to get the reference counts right.
>
Of course you can use a hash table (something similar I am doing for mod_dav
1.x currently), but it's not a very great and performant solution:
- You have a hash lookup on every function entry per structure
- You loose the connection when a structre is moved around in memory (this
doesn't happen too often, so this may not be a big problem)
- When the C struct is deleted without notice, your hash entry points to
already freed memory and you don't have a chance to reliable deteced it, so
you have a good chance getting a SIGSEGV...
- When threads come into play (APache 2.0 worker MPM) you have to deal with
locking and serialization access to this hash (in Perl you have to
addtionaly make this hash shared), which will reduce performance again.
On the one side I see your argument that you don't want to have your structs
poluted with things that don't belong to svn, on the other side it's a
common approach to have some user data member (or function argument which is
passed to callback) and it makes life so much easier when you try to do a
mapping to some other language. I think it will be even make lifer easier
for people who want to interface thier code with mod_dav or svn in C.
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Sep 2 09:29:09 2002