[TYPO3-core] RFC #16749

Dmitry Dulepov dmitry.dulepov at typo3.org
Thu Dec 16 10:16:55 CET 2010


Hi!

First of all, names of classes cannot be changed like that, without prior 
announcement two versions before the change. Somebody may use that class 
outside of the core. It is in t3lib/, so it is available for anybody. -1 to 
renaming t3lib_lock. This change is breaking, so it may not go in.

Next, we do not put many classes to one file. One class per file, please.

Next, there is a "switch" that works with files and semaphores. To code 
that properly, the class should be split to different classes for each 
locking method. "switch" in such cases is always a sign of wrong design. I 
would create a new lock/ subdirectory inside t3lib and put implementation 
classes there.

Finally, your post lacks RFC title in the subject :)

Dmitry.

Bjoern Pedersen wrote:
> Hi,
>
> This is a SVN patch request.
>
> Type: Bugfix
>
> BT reference: http://bugs.typo3.org/view.php?id=16749
> Branches:trunk
>
> Problem:The problem of already deleted lock files still exists.
>   * Solution : Add a "static" lock class and implement a lockFile-Lock.
>
>
> Another problem was, that locks that never were acquired were never
> released properly:
> The early return in release returned wrongly
> Soulution:
>    * add a destruct member and use it as second flag for the early return
>
>
> How to test:
>     The error happens normaly when accesing a page very often directly
> after cache clearing. As it is a race condition it is not really
> "reproducible".
>
>
> Note: The attached patch probably still needs some cleanup:
>   * naming of the new classes?
>   * where to store the global lock instance (Just a var in $Globals or
> maybe in $globals['TSFE'] or ... ??
>
>
> Björn

-- 
Dmitry Dulepov
TYPO3 core&security team member
Twitter: http://twitter.com/dmitryd
Read more @ http://dmitry-dulepov.com/


More information about the TYPO3-team-core mailing list