Hey,
kfogel@collab.net wrote:
>Joe Orton <jorton@redhat.com> writes:
>
>
>>the problem appears to be simply that the DB_LOCK_DEADLOCK error
>>returned by svn_fs__bdb_get_node_revision gets wrapped on the error
>>stack by svn_fs__bdb_new_successor_id, so svn_fs__retry_txn doesn't spot
>>it and retry appropriately. Or am I being stupidly naive and it's
>>really a lot more complicated than this?
>>
>>
>
>Hmmm, there could be other places in libsvn_fs where a similar mistake
>is made (that is, calling a function that could return DB_DEADLOCK,
>but blindly wrapping the error without having an exception to pass
>DB_DEADLOCK through unchanged).
>
>Joe, should I open an issue about that, or were you already auditing
>for this very thing anyway?
>
>
>
Karl are you saying that the fix to trail.c should not be committed into
repos and instead all these "mistakes" should be found and shot?
Is digging for deadlocks all that bad?
Why not let the trail worry about deadlocks and let everyone else do
what they do?
My reasons.
1. If you get rid of the mistakes today. Another will arrive next week.
2. If we *encourage* wrapping of all errors, we get more detail for
finding and perhaps removing deadlock patterns.
Or am I smokin' crack? :-)
gat
PS I have code to glue BDB DB_ENV->set_errcall into error tree. I'll
post a preliminary patch soon so folks can take a "look see".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 5 22:07:55 2003