Improve the file locking

[cmb]

Hello Community,

in CMSimple_XH 1.6 a minimal file locking based on flock() was finally implemented. As already mentionend in this thread, flock() might not work reliably on multithreaded IIS. In a French thead it turned out, that some providers forbid this function (in this case, the file locking causes include() to fail, what is a regression in CMSimple_XH 1.6, as earlier versions work fine there).

We should consider to replace our current simple flock() with a more sophisticated solution, that offers some kind of fallback for servers where flock() doesn't work as expected. As I see no possibility to detect whether flock() works properly, so we may have to introduce a new (hidden) configuration option, so the user is able to control the behavior.

A very simple solution would be to eschew the file locking when configured respectively:

Code: Select all

/**
 * Locks or unlocks an opened file and returns whether that succeeded.
 *
 * Can be disabled with $cf['files']['lock].
 *
 * @param resource $handle    A file handle.
 * @param int      $operation A lock operation constant.
 * 
 * @return bool
 *
 * @global array The configuration of the core.
 *
 * @see flock()
 *
 * @since 1.6.3
 */
function XH_flock($handle, $operation)
{
    global $cf;
    
    if ($cf['files']['lock']) {
        return flock($handle, $operation);
    } else {
        return true;
    }
} 

However, as file locking is important for concurrent environments, we should consider to fall back to some other kind of file locking, such as Holger's suggestion. In this case we have to find another name for the config variable, of course.

Please note, that this issue is not directly related to my suggestion about Request-spanning file locking and should be handled and voted upon indepently.

Finally, I want to stress that these kinds of file locking are purely advisory, i.e. they only can work properly, if everybody heeds the locks. So plugins that read/write configuration and languages files directly (not via the plugin loader), should implement file locking, what can be easily accomplished by using XH_includeVar() resp. XH_writeFile(). For working with content.htm there are XH_readContents() and XH_saveContents().

Christoph

[manu]

IMHO the solution of a configurable flock() is problematic.
As a common user how do I find out the reason of a blank screen is a non working flock()?
Isn't there a possibility to just give up file locking if flock() doesn't work (..if function_exists('flock')..) and place a warning in system info?

Code: Select all

    /**
     * Locks or unlocks an opened file and returns whether that succeeded.
     *
     * Depending of the appearance of flock().
     *
     * @param resource $handle    A file handle.
     * @param int      $operation A lock operation constant.
     * 
     * @return bool
     *
     * @global array The configuration of the core.
     *
     * @see flock()
     *
     * @since 1.6.3
     */
    function XH_flock($handle, $operation)
    {
        global $cf;
        
        if (function_exists('flock')) {
            return flock($handle, $operation);
        } else {
            return true;
        }
    } 

I have no clue it this works, because I don't know the outcome of the server where the error happened.
regards
manu

[cmb]

Isn't there a possibility to just give up file locking if flock() doesn't work (..if function_exists('flock')..)

On mimit54's server flock() does exist, and the call did not fail, but after a file had been locked, some file operations (include) just failed. This could be caused by a bug in PHP, because there is PHP/5.1.3RC4-dev installed (n.b.: a dev version of an RC!).

On multithreaded servers where flock() might not work, function_exists('flock') will return true, and most likely even calling flock() will return true.

In the general case it doesn't seem to be possible to detect if flock() really works. And actually, I'm not even sure, if there are issues on multithreaded servers as mentioned in the PHP manual, see http://news.php.net/php.general/323616 for instance.

Considering all this uncertainty, it might be best to only add a simple wrapper for flock(), which could be easily modified if need be:

Code: Select all

function XH_flock($handle, $operation)
{
    return flock($handle, $operation);
}

[manu]

+1
Then we're still free to eventually choose an alternative lock mechanism in future.

[cmb]

Done (r1345). (I have named the function XH_lockFile() to avoid to close associations to flock() and because the name is more expressive.)