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. > > >
