> From: Jeffrey E Care [mailto:[EMAIL PROTECTED]
>
> Steve Loughran <[EMAIL PROTECTED]> wrote on 10/12/2005 07:50:04 AM:
>
> > Input is another issue.
>
> That is certainly true; I had not considered the <input> task, mostly
> because in WAS we don't/can't use it. It would have to be documented
in
> the manual that using parallel subant to build projects that use the
input
> task would be verboten.
>
Well, I think that it should be quite clear to people that it only makes
sense to parallelize code that does not require manual user intervention
(i.e., manual input), you can always input from a file. In the worst
case, you can only have one of your parallelized builds do console
input.
> >
> > to an extent <parallel> is the most prone to race conditions, as it
is
> > running stuff in the same project. a subant running in parallel is
> > likely to share much less, just a FileUtils instance and maybe some
> > references handed down.
>
> Is it same to assume that we'll be running against JDK 1.2 or greater?
If
> so we could possibly convert FileUtils (or any other class with a
static
> "getInstance" singleton accessor) to use ThreadLocal.
>
I would prefer to make this objects either stateless (best thing to do)
or thread safe. To use state full static objects on the CORE sounds very
bad to me.
Also, we may want to provide a synchronization mechanism that can be
exploited by the concurrent builds.
I am thinking of probably being able to use a reference object that one
can access on the sub-builds and being able to write something like:
<synchronized refid="mylock">
....
</synchronized>
The parent build will create "mylock" and pass it to <subant>. This
should be enough to perform a lot of stuff, maybe including <input>.
<synchronized> is trivial to implement.
Jose Alberto
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
