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]

Reply via email to