Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <52B5566A.9020001@zeus.net.au>
Date: Sat, 21 Dec 2013 18:50:50 +1000
From: Peter Firmstone <jini@zeus.net.au>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB;
 rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20
MIME-Version: 1.0
To: dev@river.apache.org
Subject: Re: VOTE: add Startable to Jini specification
References: <1387274583.7396.13.camel@Nokia-N900>
 <1387361916.10544.5.camel@Nokia-N900> <52B1811E.3020909@acm.org>
 <1387366936.10790.16.camel@Nokia-N900> <1387370542.10790.28.camel@Nokia-N900>
 <B3A3F03C-B544-47E6-9A3B-DF75A018A43C@stratuscom.com>
 <1387379542.10790.62.camel@Nokia-N900> <1387413765.11482.5.camel@Nokia-N900>
 <6C1CA208-98BF-415F-8F65-A4D6800E39E8@stratuscom.com>
 <CAMPUXz-cEAAQ=OzVic9HF3mB9_ZgsCEwhLxN4TarjMCE9QcBxw@mail.gmail.com>
 <1387498686.13390.6.camel@Nokia-N900> <1387504487.13767.5.camel@Nokia-N900>
 <47E98176-3F2B-43B6-831B-5F45E5D821AD@stratuscom.com>
 <1387514976.13913.5.camel@Nokia-N900>
 <CAMPUXz-cKDyPMY6DZGQn5TXLK0Hq_Kq0F6EbqP+Vc6gYpDjDdA@mail.gmail.com>
 <52B48E89.2030604@acm.org> <CAMPUXz-uJNOhwCzhANaNRN9
 2seFZiWK33wNZQgLMccKF+JMWew@mail.gmail.com>
 <1387579080.15184.5.camel@Nokia-N900>
 <CAMPUXz8ENr308ME7J1inxJOqxo4J6i9JFWF8b7DXmB8fZDBA9w@mail.gmail.com>
 <1387585725.1425.6.camel@Nokia-N900>
 <EC2FB614-5974-4664-B19F-0469002C13A8@stratuscom.com>
In-Reply-To: <EC2FB614-5974-4664-B19F-0469002C13A8@stratuscom.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

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.