ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Charles Duffy <>
Subject Re: Cleanup callbacks in IvyContext?
Date Wed, 08 Jan 2014 15:47:43 GMT
Apologies about the delay before providing a full reply -- I was
unexpectedly stuck in Chicago without my laptop.

The problem with the LockStrategy interface is that it's too fine-grained
for the use case wherein a read lock needs to be held for the duration of a
high-level operation.

Consider the case where a user calls ivy:resolve, ivy:retrieve and
ivy:report in sequence. An ivy:clean run by an external process between any
of these operations would cause a failure, and would be prevented by any
proper repository-wide read-lock mechanism.

The above _does_ indicate a potential problem with the proposal I opened
this thread with -- inasmuch as it doesn't provide a way to hold locks
spanning multiple high-level operations while still putting each of those
operations in a separate IvyContext. I wonder if it might make sense to
allow a given member in the stack to indicate that it should hold locks its
children. For ant, being generally a short-lived process, it might make
sense for the parent context to be the read lock holder.

Does this clarify the issue I'm trying to solve?

On Sat, Jan 4, 2014 at 8:06 AM, Nicolas Lalevée

> Le 3 janv. 2014 à 22:28, Charles Duffy <> 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:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message