This is part of why I wouldn't give it knowledge of locks specifically, but simply Runnable callbacks to invoke on pop -- not specifically tied to a single use case. This is not entirely unlike atExit calls available through the JVM, the standard C library, etc.
Improving LockStrategy is a necessary component, to be sure -- but something needs to tell it when a read lock is needed, and likewise when its need is past. On Jan 4, 2014 8:07 AM, "Nicolas Lalevée" <nicolas.lale...@hibnet.org> wrote: > > Le 3 janv. 2014 à 22:28, Charles Duffy <char...@dyfis.net> a écrit : > > > Howdy, all -- > > > > I'm trying to strengthen Ivy's locking system to make it strong enough to > > allow ivy:clean at arbitrary times on systems which can have other > actions > > making use of the same shared caches. > > > > There are a few requirements to make this happen while still allowing > > multiple resolves (and like operations) to occur concurrently. One of > those > > is maintaining nonexclusive read locks (as opposed to the write locks > which > > are currently supported), and cleaning them up when necessary. For > > ease-of-implementation, I'm currently proposing to only support this > > behavior when NIO locks (which implicitly support shared locking > semantics) > > are enabled. > > > > To clean these locks up without requiring end-user code to be modified, I > > propose using the IvyContext stack -- allowing Runnables to be attached > to > > a stack element, and invoking them implicitly when the stack is popped. > > > > > > Because converting a read lock to a write lock is inherently prone to > race > > conditions, we might need to break backwards compatibility with respect > to > > ivy:clean, allowing this to be called only inside a context where no read > > operations have been done -- or breaking read lock semantics by dropping > > all read locks before grabbing the write lock. > > > > > > Thoughts? > > My first blind though would be that IvyContext seems to be high level to > handle locking. Couldn't it be done by improving the LockStrategy interface > so that it also handles read locks ? > > Nicolas > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > >
