river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: VOTE: add Startable to Jini specification
Date Sat, 21 Dec 2013 21:39:03 GMT
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<jini@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.
> > > > 
> > > 
> > 
> > 
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message