Josh Pieper <jjp@pobox.com> writes:
> b) Temporarily disable the interrupt handler during possibly hanging
> network operations. It could be tricky, because it's hard to tell
> what could be allocated in pools that won't be cleaned up. This
> also seems like a very naughty thing for a library to do.
>
> c) Make subversion multi-threaded and push off all possibly hanging
> network operations into other threads. Very complicated, but I'm
> including it for completeness.
>
> c) Do nothing... a user may need to use kill -9 in order to
> interrupt svn if a network operation hangs.
>
> Are there any other options and/or opinions? I'm leaning towards the
> last option, but I want to see if there are any other ideas or
> objections.
I think (b) may be feasible, actually.
What if Subversion offered an API (a callback, perhaps) to the RA
layers, such that an RA layer had a way to save, disable, and restore
the client's special interrupt handling. The RA layer knows when it's
going to go into some possibly hangy network operation. It could
'save(&baton)' and 'disable()' the interrupt handler right before
entering that code, then 'restore(baton)' right after.
I'm speaking casually here, without fully designing the callback
interface, but I'll bet potential pool lifetime problems could be
solved with the right baton discipline...
Thoughts?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 2 20:46:51 2004