Keep only one file handle open #7

Open
wants to merge 5 commits into
from

2 participants

@mburtscher

This pull request fixes issue #6: Only one file handle should be kept open at a time. Only the Filesystem class has been touched.

Description

The Filesystem object with an open file handle is always stored in the static field Filesystem::$openFile. If a new file handle is created, the currently active one will be closed. Before each file operation the handle is opened again and seeked to the previous position.

This also allows operations like this to perform well because file handle is not closed until a new one is created:

$file = new Filesystem("test.txt");
$file->lock(),
$file->write("a");
$file->write("b");
$file->write("c");
$file->unlock();
$file->close();

Example

$file1 = new Filesystem("file1.txt");
$file2 = new Filesystem("file2.txt");
$file1->lock(); // File handle for file1.txt is opened
$file1->write("a");
$file2->write("b"); // File handle for file1.txt is closed, file handle for file2.txt is opened
$file1->unlock(); // File handle for file2.txt is closed, file handle for file1.txt is opened
$file1->close(); // File handle for file1.txt is closed
$file2->close();
@mburtscher

@Maks3w Please review the changes. Unit-tests are working just like before. But one of them fails anyway (SegmentInfoTest::testDelete())...

@mburtscher

@Maks3w Anyone out there to review? We'd be glad to see this one in master for easier future maintenance ...

@Maks3w
Zend Framework member

Uff, This looks to be a very ugly solution. I think that is better try to fix the part of the code which creates and keep running so many FileSystem objects.

Also does not optimize the I/O bus requiring so many close and open operations

@mburtscher

You are right that this is not a very clean solution. We first tried finding the code that keeps so much file-handles open but it seems that this happens in various sections of the code. It also seems that real file locking is required to prevent multiple instances from accessing the index at a time.

I agree that this solution does not optimize I/O bus but we could not figure out a solution that is clean, performant and solves the problem.

From your argumentation I expect that you won't merge this solution so we will look further into the issue. If we can't find a cleaner solution we will maintain the fork for our individual needs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment