Den 26.04.2010 14:40, skrev Jason van Zyl:
On Apr 26, 2010, at 7:05 AM, Benjamin Bentmann wrote:
IMHO, there's only way to limit this "oh, I deliberately enabled nitro injection and
now my engine blew up, how am I supposed to know that this is dangerous?": Unless a
mojo is explicitly marked with @threadsafe, issue a warning like
LOL. I think you're right. Enable nitro injection, you get warnings for
any plugin not marked @threadsafe. If the build fails too you get an
additional warning at the end that
you're running on your own, please go see our marvellous wiki site.
Right. It's pretty simple. If the author has worked on and tested then they can
mark the mojo as such. Otherwise the mojo gets no benefit from the parallel
mode.
A @nothreadsafe annotation makes no sense. We're going to go around and mark
everyone else's mojos? That's not going to work and neither is maintaining
third party information. If we start the process of adding the annotation we
can easily get the basic mojos in the default lifecycle annotated accordingly.
If we deem this a requirement for the 3.0 release then we'll work on plugins
for a little while before releasing 3.0.
@notthreadsafe/@noparallel makes only marginal sense, since you'd
achieve the intended effect by sunchronizing execute.
But on the other hand I suppose a thread-reluctant mojo would end up
with a "@threadsafe" annotation and
a synchronized execute method. But it shows that threading has been
considered, which is fine with me.
I think an important issue to settle is if the annotations should have
any impact on run-time behaviour (other than complaining...)
I somewhat dislike the idea of only running mojos marked with
@threadsafe concurrently; it also decreases overall performance and
increases risks of
deadlocks in weave mode significantly. And you're only getting
parallel-mode because you asked for it, right ?
So my 2cents are: Add @threadsafe annotation, complain loudly about
executions missing annotations but proceed as requested. Increases
community motivation to make plugins thread-safe.
This solution would allow future extensions if required.
Kristian
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]