lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Jordan <robe...@gmx.net>
Subject Re: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to Ensure Flush to Disk
Date Wed, 11 Nov 2009 11:40:00 GMT
George Aroush wrote:
> For 2.9, we have just this one place in Lucene.Net code that requires
> special attention for Mono support.  My vote goes for a quick and simple
> solution.  Who is up for providing a patch?

I'll do.

Robert

> 
> -- George
> 
> -----Original Message-----
> From: Michael Garski [mailto:mgarski@myspace-inc.com] 
> Sent: Tuesday, November 10, 2009 8:01 PM
> To: lucene-net-dev@incubator.apache.org
> Subject: RE: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to
> Ensure Flush to Disk
> 
> I really like the idea of breaking out platform-specifics to an
> interface.  In that way users of Mono or any other platform can
> implement their own interface if one of the provided implementations
> does not meet their needs.  This may not be the best example, but if
> Mono on Linux needed one implementation, OSX another, and Solaris
> another, XBOX another (good example BTW :) ) then those users can whip
> up their own.
> 
> Now for what is 'platform-specific'... IMHO I see it not as
> language/runtime version issues but underlying OS differences such as
> IO.  
> 
> Michael
> 
> -----Original Message-----
> From: Nicholas Paldino [.NET/C# MVP] [mailto:casperOne@caspershouse.com]
> 
> Sent: Tuesday, November 10, 2009 9:41 AM
> To: lucene-net-dev@incubator.apache.org
> Subject: RE: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to
> Ensure Flush to Disk
> 
> 	I don't have a problem with that.  I'd prefer to see the check
> be a check 
> against != (PlatformID.Win32NT || PlatformId.Win32Windows):
> 
> - I'm not sure how XBOX would make the P/Invoke call.
> - WinCE requires a separate P/Invoke declaration (to using "Coredll.dll"
> as 
> the dll name).
> - Win32s isn't even in existence anymore, AFAIK, and if it is, I can't
> imagine 
> .NET 2.0 apps are running on it.
> 
> 	However, with your approach, I prefer to see the result of the
> boolean check 
> above placed into a readonly static variable and then check that at the
> call 
> site.  There is no reason to make that call each and every time before
> the 
> call to the API.
> 
> 	As for too much abstraction, I disagree, given that is exactly
> what is done 
> for compression support and I'd prefer not to see platform specific
> checks 
> anywhere in the code.  If at some point Lucene.Net is going to say to
> Mono 
> "sorry, we have to move forward" (and that was hinted at when commits
> are in 
> sync with Java, with a desired timeline of 2.9 or 3.0), then this option
> is 
> what allows Mono to still participate, since chances are
> platform-specific 
> code will be rooted out after that point.
> 
> 	However, an abstraction like this would allow Mono to still use
> this 
> functionality.
> 
> 		- Nick
> 
> 
> -----Original Message-----
> From: news [mailto:news@ger.gmane.org] On Behalf Of Robert Jordan
> Sent: Tuesday, November 10, 2009 11:41 AM
> To: lucene-net-dev@incubator.apache.org
> Subject: Re: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to
> Ensure 
> Flush to Disk
> 
> Nicholas Paldino [.NET/C# MVP] wrote:
>> 	I disagree, since compile time switches seem to be unfavorable
>> moving forward (based on the comments), the alternative that would
> satisfy
>> both concerns is to have a setting which indicates the Type which
> implements
>> an interface which will perform the flush on a FileStream instance.
> If the
>> setting is null, have a default implementation which resorts to the
> native
>> API call.
> 
> Too much abstraction. It could be as simple as this:
> 
> if (Environment.OSVersion.Platform == PlatformID.Unix ||
>      Environment.OSVersion.Platform == PlatformID.MacOSX) {
>      // do nothing for know
> } else {
>      FlushFileBuffers (...);
> }
> 
> I'll provide a patch for Mono once this or a similar
> code is committed.
> 
> Robert
> 
>> 	Then the Mono crowd can then write their own hook for this
>> functionality and set the setting in the config file.
>>
>> 		- nick
>>
>> -----Original Message-----
>> From: Sean Carpenter [mailto:stcarpenter@gmail.com]
>> Sent: Tuesday, November 10, 2009 10:27 AM
>> To: lucene-net-dev@incubator.apache.org
>> Subject: Re: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to
>> Ensure Flush to Disk
>>
>> I think conditional compilation will be the solution for anything that
>> requires P/Invokes (at least for now).
>>
>> Sean Carpenter
>>
>> On Tue, Nov 10, 2009 at 10:07 AM, Ben Martz <benmartz@gmail.com>
> wrote:
>>> P/invokes are unsupported in mono because the target platform dll
> only
>>> exists on Windows so there's nothing to thunk to on Linux, Mac OS X
> and
>> the
>>> iPhone OS. :(
>>>
>>> Sent from my iPhone
>>>
>>> On Nov 10, 2009, at 5:11, "George Aroush" <george@aroush.net> wrote:
>>>
>>>> This is good to know.  How about code like this:
>>>>
>>>>   [System.Runtime.InteropServices.DllImport("kernel32")]
>>>>   public static extern int
>>>> FlushFileBuffers(Microsoft.Win32.SafeHandles.SafeFileHandle
>>>> SafeFileHandle);
>>>>
>>>> Will this work with Mono?
>>>>
>>>> -- George
>>>>
>>>> -----Original Message-----
>>>> From: Sean Carpenter [mailto:stcarpenter@gmail.com]
>>>> Sent: Tuesday, November 10, 2009 7:26 AM
>>>> To: lucene-net-dev@incubator.apache.org
>>>> Subject: Re: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix
> to
>>>> Ensure Flush to Disk
>>>>
>>>> I've done some work with Lucene.Net on Mono, so keeping it running
>>>> there is important to me.  As for issues related to the future move
> to
>>>> .Net 3.5, Mono has support for 3.5 including LINQ, so that shouldn't
>>>> be a concern.  The P/Invokes are the biggest concern to me.
>>>>
>>>> Sean Carpenter
>>>>
>>>> On Tue, Nov 10, 2009 at 12:44 AM, Michael Garski (JIRA)
> <jira@apache.org>
>>>> wrote:
>>>>>   [
>>>>
> https://issues.apache.org/jira/browse/LUCENENET-216?page=com.atlassian.j
> ira.
> plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12775305#
> acti
>>>> on_12775305 ]
>>>>> Michael Garski commented on LUCENENET-216:
>>>>> ------------------------------------------
>>>>>
>>>>> Sounds like a good course of action for now.  Hopefully some of the
> Mono
>>>> Lucene.Net users will see this thread and chime in.
>>>>> I'll create a new patch with conditional compilation and with
> Nick's
>>>> suggestion on the mailing list earlier regarding security.
>>>>>> FSDirectory.Sync Fix to Ensure Flush to Disk
>>>>>> --------------------------------------------
>>>>>>
>>>>>>                Key: LUCENENET-216
>>>>>>                URL:
> https://issues.apache.org/jira/browse/LUCENENET-216
>>>>>>            Project: Lucene.Net
>>>>>>         Issue Type: Bug
>>>>>>           Reporter: Michael Garski
>>>>>>        Attachments: FSDirectory.Sync.patch
>>>>>>
>>>>>>
>>>>>> DIGY and Doug discussed this issue during the 2.9 port, and this
> is a
>>>> patch to give 2.9 the expected behavior of actually ensuring the OS
>>>> flushes
>>>> it's buffers to disk.  DIGY suggested using the kernel32 method
>>>> FlushFileBuffers, and after investigation he was correct!
>>>>  FileStream.Flush
>>>> doesn't do that - the OS could still be caching it.
>>>>> --
>>>>> This message is automatically generated by JIRA.
>>>>> -
>>>>> You can reply to this email to add a comment to the issue online.
>>>>>
>>>>>
> 
> 


Mime
View raw message