ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Charles Duffy <char...@dyfis.net>
Subject Re: Cleanup callbacks in IvyContext?
Date Sat, 04 Jan 2014 17:31:08 GMT
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.lalevee@hibnet.org>
wrote:

>
> Le 3 janv. 2014 à 22:28, Charles Duffy <charles@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-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>

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