> From: Garrett Rooney [mailto:rooneg@electricjellyfish.net]
>
> On Tuesday, September 17, 2002, at 07:39 PM, Philip Martin wrote:
>
> > Garrett Rooney <rooneg@electricjellyfish.net> writes:
> >
> >> the last remaining question is "if signal itself isn't portable, is
> >> sig_atomic_t?" according to all i've read, and what philip has
said,
> >> about the only thing that's safe to do in a signal handler is to
set a
> >> sig_atomic_t variable... if that typedef isn't considered
portable,
> >> it complicates life considerably...
> >
> > apr_atomic_t? It appears to be unsigned int on my platform, whereas
> > sig_atomic_t is plain int. That probably doesn't matter, and if it
> > does it's APR's problem!
>
> the thing that worries me about apr_atomic_t is that if atomic ops
> aren't available on the platform, it falls back to an implementation
> using mutexes, which means that apr_atomic_{inc,dec,get,set} wouldn't
> be safe to use in a signal handler.
>
You know if synchronization structures aren't safe to use inside a
signal handler, then your platform is in pretty sad shape.
If apr_atomic_t isn't good enough, then you might as well just mark the
state variable as volatile. You still won't get perfect SMP cache
coherency, but at least you'll be slightly better off. My take on APR's
apr_atomic_t is that some preprocessing symbol should be defined if
apr_atomic_t operations aren't simple assembly instructions ala "lock
xchg" on x86, etc.
Oh yeah, and what are you thinking having only one user cancellation
handler?
i.e. Why is this state global?
There was a good reason that the cancellation editor was written, it's
so that the cancellation handler could be specified for each particular
and interesting operation.
Doing it this way lets the user application maintain its state however
it wants, and not in some bizarre way that's necessitated by
Subversion's API choice.
It just so happens that the command line client doesn't care so much,
but other more sophisticated users of the API might.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 18 07:17:07 2002