Le 8 janv. 2014 à 16:47, Charles Duffy <char...@dyfis.net> 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 ? Nicolas > > > On Sat, Jan 4, 2014 at 8:06 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 >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
