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
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
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
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
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.
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
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Jun 6 22:48:31 2003