Howdy, At 11:48 31/1/01 +1100, Conor MacNeill wrote: >Stefan, > >From: "Stefan Bodewig" <[EMAIL PROTECTED]> >> >> So let me chip in, even if I don't have a very strong opinion on it >> either. >> >> To me it's quite clear that asking, whether a TaskContainer concept >> (I'd prefer that name as well) is desirable, boils down to "Do we want >> to make it easier to write a foreach or a switch/case task?". >> > >Lets look, instead, at Thomas' motivation for the TaskContainer - >multithreading of tasks.
I think there is two different discussions going on. a) do we need/want TaskContainers b) how do we parrelize (I assume that everyone is +1 to idea of parrallizing) In regards to (a) then I think we need to look at the cost/benefit ratio. In Ant2.x due to the usage of proxies/taskData containers/TOMs/whatever it will be a low cost operation. The only cost comes to the developer who actually writes the TaskContainer. With an applicable base class this could even be minimised via an AbstractTaskContainer. However in Ant1.x it comes at a steeper cost. I haven't looked at the recent patch but if it was the same one submitted a while back then it does cost a little bit. It added a bit to the complexity of the ant runtime and a bit to general complexity of some task writers (though a minority). So in Ant1.x it costs more. What does it give us? It allows others (NOT us ;-]) to develope if/then/else/switch/whatever with relative ease. They could take the ant runtime and turn it into a general scripting language. While we shouldn't condone it or accept such patches I don't see a problem with allowing this. It could even gain us some developers/users from projects like xml-shell ;) So the question is - do you think it is worth the extra complexity to allow this? It could potentially harm our users in long run if they inadvertently start using if/switch/whatever (thou it could also do good for small build environments). Realize also that it will be a completely and utterly unsupported in Ant2.x as it will do things differently. Me I don't like the complexity and don't plan to help maintain it but if there is people who are willing to do so then that is fine. I would not veto it if we placed a "Danger Wil Robinson ! Danger !" sign indicating that it is unsupported in future iterations. So I guess the overall would be a +/-0 (Not much help am I ;-] ) With regards to parrelizing. I believe that the smallest user executable action is the target and should stay that way. Hence threading does not belong at the task level but at target level. Hence I see something like <target name="foo" async="true"> ... </target> as better. But before we decide on the syntax we should first analyze use case. Where will it be used and why will it be used. So far I have seen two examples - "MUST NOT async", "MUST async" and "MAY async". The MUSTers involved your starting of web-logic server and then second test-framework. The MAYers involved full utilisation of machine resources. MUST NOTers are traditionalist where tasks have indirect dependencies (ie files are generated etc). Have I missed anything or is there another use case ? Given this how do we build the syntax. As async is a feature of context target is executed in we should be doing it at the level above where target it is called IMHO. That is the only place where we can be sure of dependencies. Hence I think the async belongs associated with depends tag of target. Possible solutions include an extra attribute async=Wont|Will|Can (with "wont" being default) another solution involves having multiple versions of depends (ie async-depends, can-async-depends and normal depends). However this relies on user being aware that these options are mutually exclusive. Anyways thats my take but I haven't followed the thread real close ;) Cheers, Pete *-----------------------------------------------------* | "Faced with the choice between changing one's mind, | | and proving that there is no need to do so - almost | | everyone gets busy on the proof." | | - John Kenneth Galbraith | *-----------------------------------------------------*
