[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] experimental FS set_errcall logging

From: Sander Roobol <phy_at_wanadoo.nl>
Date: 2003-06-14 16:32:23 CEST

Filed as issue #1358.

Sander

On Fri, Jun 06, 2003 at 04:45:38PM -0400, Glenn A. Thompson wrote:
> Hey,
>
> When Karl mentioned wanting a patch for set_errfile logging stuff I
> decided to try my hand at it.
>
> Here some things that drove my approach.
>
> 1. I believe that using set_errcall is more flexible than using
> set_errfile.
> 2. Being flexible, it will better allow us to hook into something like
> http://log4c.sourceforge.net/. I said *like* :-)
> 3. Also allows the detail to be returned in the error chain. Which is
> helpful when server and user are not co-located.
> 4. In case of an error, BDB would have to call the CB function before
> returning control to the caller. It would be useless otherwise.
> I could save it and use it later.
> 5. It seemed possible that BDB may also call the callback more than
> once for certain errors or call it when not reporting an error.
> 6. To cover the case where no error is returned I need to cleanup the
> leaky messages.
> 7. BDB does not provide "REAL" opaque user_data. They expect the error
> prefix to be a C string.
> If you read: http://www.sleepycat.com/docs/api_c/db_err.htm and
> http://www.sleepycat.com/docs/api_c/env_set_errpfx.html
> You will notice that it maintains a reference to the prefix and
> does not add it to the message when a set_errcall has registered
> a callback. So we have a cheesy userdata field. (More on this to
> follow).
>
> The approach:
>
> 1. Register a callback which creates svn_error_t's and chains them off
> each other saving them in the svn_fs_t object.
> 2. When an error occurs, detach the error chain and use it as the child
> parameter to the svn_error_create call.
> 3. Mutex protect these operations so multiple threads can use the the
> same fs object.
> 4. Clear out the error chain when svn_fs_t object goes out of scope.
>
> Some caveats:
> 1. It's not completely tested. "experimental"
> 2. The changes that are in tree.c were just a cheesy way to test. I
> patch tree.c then run a couple stress.pls.
> Tree.c is not part of the patch. I simulate BDB error logging
> using err and errx.
> 3. I have two ways I pass the fs object through the callback:
> One which uses the pointer(way to dangerous) in the prefix
> parameter and the other which places the addr as a string in the prefix
> parameter. Currently it uses apr_snprintf and scanf for this, but
> I could roll my own for both sides if folks think it will be safer.
> 4. If folks want the patch I'll write a *real* test for this patch. If
> not, it was worth the shot. We can file it under /dev/null.
>
> The patch and log entry are at
> http://www.cdrguys.com/subversion/logpatch1.tar
>
> gat
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 14 16:33:10 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.