Say what? There's no personalities involved here.
It's simple, anything that comes between me and the source is unnecessary and
just gets in the way of deploying and using Lucene.NET
- Neal
-Original Message-
From: Troy Howard [mailto:thowar...@gmail.com]
Sent: Wednesday, September 2
Michael,
Troy is indeed right in that I was referring to Neal's email and not yours.
That was a mistake on my part and anything that sprung from that mistake
was unintended and I apologize for that.
For the rest, see inline.
The last e-mail was out of l
Before I go replacing all the volatile fields I wanted to run this past the
list:
private System.IO.StreamWriter infoStream;
into
private object o = new object();
private System.IO.StreamWriter _infoStream;
private System.IO.StreamWriter infoStream
{
get
{
The line before had volatile in it..
private volatile System.IO.StreamWriter infoStream;
> From: geobmx...@hotmail.com
> To: lucene-net-dev@lucene.apache.org
> Date: Thu, 22 Sep 2011 20:14:41 -0700
> Subject: RE: [Lucene.Net] 2.9.4
>
>
> Before I go re
Prescott,
You really don't need to do that; reads and writes of reference fields are
guaranteed to be atomic as per section 5.5 of the C# Language Specufication
(Atomicity of variable references)
If you were doing other operations beyond the read and write that you wanted to
be atomic, then th
On 2011-09-22, Danijel Kecman wrote:
> i would like to contribute.
welcome Danijel.
The best way to start contributing is by looking at the issues in JIRA
pick one and start providing patches there - as well as engaging in
discussion on this list.
Cheers
Stefan
I see, so you're essentially saying, I can simply remove the volatile keyword
in this case, and it's exactly the same becuase I am only using it for read and
writes?
So the case I'd need to be more careful of is if an manipulation method is
called on the object itself - suppose:
public