ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <>
Subject Re: Cleanup callbacks in IvyContext?
Date Thu, 09 Jan 2014 18:17:59 GMT

Le 8 janv. 2014 à 16:47, Charles Duffy <> a écrit :

> Apologies about the delay before providing a full reply -- I was
> unexpectedly stuck in Chicago without my laptop.

No worries, I am myself usually random in my response time, due to my sparse free time.

> 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?

Yep, a quite hard problem to resolve. At the ant task level I don't know how you could nail
it without asking the end user to call some ivy:lock task.

I myself don't have much experience with file based lock mechanism between different process.
For instance what happens if a process holding a lock is killed -9, or whatever which make
the jvm not even able to trigger its shutdown hooks ?


> On Sat, Jan 4, 2014 at 8:06 AM, Nicolas Lalevée
> <>wrote:
>> 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:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message