Le 9 janv. 2014 à 19:43, Charles Duffy <char...@dyfis.net> a écrit :

> On Thu, Jan 9, 2014 at 12:17 PM, Nicolas Lalevée <nicolas.lale...@hibnet.org
>> wrote:
> 
>> 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'd like to argue that for ant tasks, a default behavior of releasing locks
> only on process shutdown should be adequate -- ant invocations not being
> long-lived by nature.

I was just thinking about locking the usual configure - resolve - retrieve - 
report, but I forgot that to run tests you need a classpath which needs to 
continue to exist on disk. You're right, releasing at shutdown seems to fit 
every usual use case.

> IDE plugins alter this a bit... but then, is it really safe to delete
> caches while a running IDE expects them to persist?

I think there will be some trouble with Eclipse users if IvyDE starts using 
locks. I remember IvyDE bugs on Windows where users would complain they cannot 
delete files because IvyDE via Eclipse was holding a reference to them. Since 
it is in an IDE and humans have only one brain, let's assume they only do one 
thing at a time, they are not ivy:cleaning via ant and running something in 
Eclipse at the same time, at least not on a daily basis. If they do, then thing 
will expectedly break, and the break is quite understandable.
And actually Eclipse is having a layer of cache upon the filesystem, which make 
errors on file search if the cache is not in sync, generate unsolvable bugs 
[1]. So I guess it will be OK if Eclipse show errors on such concurrent use 
case, users should be used to it.

To come back to the original topic, and to answer the use case about allowing 
to "safely" run an ivy:clean next to an ivy:resolve-and-others, for instance 
for the use case of a CI server, the IvyContext will not have an enough wide 
scope. The jvm shutdown hook should be better used, right ? And it should be 
optional so that in IDE like in IvyDE, locks can be disabled and won't be an 
issue.

>> 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 ?
>> 
> 
> I would only propose to support this with NIO locks in use. These are
> implicitly released on file descriptor release, even when this is caused by
> SIGKILL, power termination, etc.

I didn't know, that is nice.

Nicolas

[1] https://issues.apache.org/jira/browse/IVYDE-302
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Reply via email to