Thank you.
----- Original message ----- > I'll try. I really think there are three strategies that should be > considered separately: > > 1. Fix concurrency bugs in River code, even if the bug can only be > identified in theory, without causing any known external symptoms. > > 2. Externalize some or all of any facilities that are added to implement > Strategy 1, so that users can apply them in their own code. > > 3. Log non-use of Strategy 2 facilities in order to encourage users to > use them. > > I'm going to use Startable as an example to illustrate the differences > between these strategies. > > Adding Startable to a River implementation package, and using it in > River code, is a Strategy 1 item. It would not call for a separate vote, > but would be voted on as part of a release candidate that implements > Strategy 1. > > Putting Startable in a package users are expected to use directly, > documenting it as part of River's external interface, is a Strategy 2 > item. It is an external interface change, and needs to be voted on > accordingly. > > Logging non-use of Startable is a Strategy 3 item, and is also an > external interface change. > > Patricia > > > On 12/21/2013 3:11 AM, Peter wrote: > > Yes it's a difficult decision, originally when I set out to fix the > > issues I found, I didn't expect to be here today, on one hand, I'd > > like to complete the work I started, I've invested too much time to > > walk away now. > > > > On the other hand, "The community" may not want it fixed. > > > > Patricia, you're much better at communicating the development > > concepts, can you do me a favour and put forward a vote proposal, it > > would be beneficial to all parties to come to some decision on the > > underlying issue. > > > > Regards, > > > > Peter. > > > > > > ----- Original message ----- > > > I have not seen any evidence of lack of understanding. I believe > > > there is a genuine lack of consensus on how to deal with some of > > > these ordering issues. > > > > > > In particular, to what extent should River live with code that will > > > almost always work? > > > > > > The damage from export-from-constructor with final fields comes if > > > another thread references the object before it is fully constructed. > > > Generally, the chain of instructions from the export to another > > > thread seeing the reference is far longer than the chain of > > > instructions from the export to the end of the constructor. Almost > > > always, the constructor will finish first and the code will work. > > > > > > Personally, I would not want to depend on that, because page faults > > > and operating system interrupts with resource contention can stretch > > > out a few instructions to several milliseconds or even seconds. > > > > > > However, a project like River depends on reaching consensus and that > > > in turn depends on discussing issues with respect for all points of > > > view. > > > > > > Patricia > > > > > > On 12/21/2013 12:50 AM, Peter Firmstone wrote: > > > > I think the real problem is some people haven't been reading up on > > > > concurrency and are insufficiently informed to be able to properly > > > > discuss the issue. > > > > > > > > When I don't know something, I either ask someone who does, or I > > > > keep my mouth shut so as not to look like a fool. > > > > > > > > It's more a case of, if you behave like a fool long enough to make > > > > it frustrating, that's exactly how you'll be treated. > > > > > > > > Sadly it's by people who should know better, who while they may > > > > lack an understanding of the JMM are still very skilled > > > > programmers, that's what makes it frustrating. > > > > > > > > Final fields are made visible after construction completes, so when > > > > other threads receive a copy of the object in an unconstructed > > > > state, like they do during export in a constructor, then those > > > > threads can continue to see the incomplete object, rather than the > > > > fully constructed one. > > > > > > > > See for yourselves, look at all the final fields in Mercury, then > > > > realise that it's reference escaped during construction. The > > > > other services are also guilty. > > > > > > > > That also means that all the remote method invocations wrapped up > > > > as runnable tasks and executed on Mercury's methods in an executor > > > > pool will have also seen parts of Mercury in a partially > > > > constructed state. > > > > > > > > http://svn.apache.org/viewvc/river/jtsk/skunk/qa_refactor/trunk/src/com/sun/jini/mercury/MailboxImpl.java?r1=545310&r2=1552606 > > > > > > > > > > > > If I haven't convinced you, read up, spend some time on the > > > > concurrency interest mail list or ask someone you trust who does > > > > know. > > > > > > > > Regards, > > > > > > > > Peter. > > > > > > > > On 21/12/2013 11:10 AM, Greg Trasuk wrote: > > > > > (off-list) > > > > > > > > > > Peter: > > > > > > > > > > You’re sounding unprofessional, and you’re missing the fact that > > > > > people are giving reasonable and well-thought-out feedback. > > > > > You seem to be taking the conversation personally. Perhaps > > > > > you should take a few hours off the list and cool down. > > > > > Things will still be here when you’ve regained composure. > > > > > > > > > > Best regards, > > > > > > > > > > Greg. > > > > > > > > > > On Dec 20, 2013, at 7:28 PM, Peter<j...@zeus.net.au> wrote: > > > > > > > > > > > You just did. > > > > > > > > > > > > The blue pill. > > > > > > > > > > > > I prefer the truth, it's easier in the long run. > > > > > > > > > > > > Feel free to cast your vote. > > > > > > > > > > > > Peter. > > > > > > > > > > > > ----- Original message ----- > > > > > > > Peter, > > > > > > > > > > > > > > There's so many things wrong in there, I'm not even going to > > > > > > > dignify this > > > > > > > with a response. > > > > > > > > > > > >
