RE: RE: Cancelling Subversion operations

> > The logical extension if you wanted more expressive power is for SVN
> > to use thread-local storage to store the user context, but that seems
> > rather more effort than it's worth.

> If memory serves, thread-local storage isn't nearly as efficient as you
> might think on all OSs. It certainly is very efficient on Windows.

The three implementations I know of are:

Mask the stack pointer to get at it -- used by Windows I think.

Look in an otherwise unused CPU debug register to get at it --
used by BeOS I think.

Look it up in a hash table from thread ID -- used on MacOS I
think.

If someone good at Linux, Solaris and BSD internals could fill
in the details for those OS-es, I'd appreciate it (just for my
personal edification if nothing else).

Anyway, if testing for cancellation involves looking up in a
hash table every time you do it, that might possibly actually
show up in a profiler (even when compared to, say, network or
disk I/O...)

I guess the main point is that with the current suggested
implementation, there actually is sufficient expressive power
to make a threaded GUI implementation only cancel one of several
outstanding requests, even if there is only one global baton.
And only that threaded GUI implementation actually needs to worry
about whether TLS is efficient or not.

Cheers,

                                / h+

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 19 01:21:50 2002