Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Received-SPF: pass (nike.apache.org: domain of charles@dyfis.net designates
 209.85.213.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4543AD26-D4B3-47EB-9A8A-F84A7825FF19@hibnet.org>
References: 
 <CAEHm_sjCjhXBQ8Jo979_osG4xYqXs5GrS-VkYPrsaZqcBtw+ug@mail.gmail.com>
	<4543AD26-D4B3-47EB-9A8A-F84A7825FF19@hibnet.org>
Date: Sat, 4 Jan 2014 11:31:08 -0600
Message-ID: 
 <CAEHm_sgrR8fw=RV6eyHq4Eg7_KHzk-iFp1MMRp31Fo=bFZ33qg@mail.gmail.com>
Subject: Re: Cleanup callbacks in IvyContext?
From: Charles Duffy <charles@dyfis.net>
To: Ant Developers List <dev@ant.apache.org>
Content-Type: multipart/alternative; boundary=089e013d09ae66b00104ef286446

--089e013d09ae66b00104ef286446
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=C3=A9e" <nicolas.lalevee@hibnet.org>
wrote:

>
> Le 3 janv. 2014 =C3=A0 22:28, Charles Duffy <charles@dyfis.net> a =C3=A9c=
rit :
>
> > 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 re=
ad
> > operations have been done -- or breaking read lock semantics by droppin=
g
> > 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 interfa=
ce
> 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
>
>

--089e013d09ae66b00104ef286446--