Garrett Rooney <rooneg@isris.pair.com> writes:
> On Sat, Sep 14, 2002 at 10:39:31AM +0100, Philip Martin wrote:
> > Branko ÄŒibej <brane@xbc.nu> writes:
> >
> > I hadn't considered the pool problem, I think we may need to get the
> > application to register the cancellation pool first.
Or perhaps we don't need to provide a pool, could we use SVN_ERROR_POOL
via svn_error__get_error_pool?
>
> that was my first instinct as well, but is there any reason it can't
> be passed in with the cancelation function?
The hard part is guaranteeing memory visibility. After the
cancellation pool pointer gets changed by the asynchronous signal
handler you need to ensure that when the pointer next gets accessed
synchronously the change will be visible. When the cancelled flag
first indicates that cancellation is required, the cancellation pool
pointer must have the right value. On lots of systems 'volatile' is
enough to do this for a pointer. Further, if the Subversion code has
the pointer in one compilation unit, and it gets accessed from other
compilation units via function calls it may work even without
'volatile'. However, to *guarantee* that it works, without having to
worry about compiler or CPU optimisations, is hard.
Of course having the client register an "is cancellation required"
callback that gets called synchronously, rather than providing an
asyncronous "set cancellation" function, moves all these problems out
of the library into the client. The client is then free to abuse the
rules as it sees fit!
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Sep 14 17:22:23 2002