stephane.ducasse at free.fr
Mon Dec 26 22:23:06 CET 2005
may be you should contact tim and john because there are nice persons?
On 26 déc. 05, at 19:52, Lukas Renggli wrote:
>>> Squeak file IO is ****ed (example http://bugs.impara.de/view.php?
>> This bug has nothing whatsoever to do with omnibase. It's simply that
>> source-code access hasn't been touched since the long forgotten days
>> of MVC.
> Yeah, that particular bug is unrelated to OmniBase, but still there
> are some problems in the Squeak filesystem-support related to
> - StandardFileStream>>size does return return wrong results, because
> it is (wrongly) cached within the VM, if the same file is opened by
> different (native or squeak) processes at the same time. This
> particular problem is well known and we already complained several
> times, but nobody is willing to remove that EVIL and INVALID caching
> from the VM! Well, I could even fix it by myself, but I don't know how
> to commit VM changes ...
> - Interval>>includes: that is used by OSProcess to simulate
> Windows-Filesystem file-locking is extremely slow. A few days ago
> there was a discussion in the VisualWorks mailing-list and some years
> ago one in comp.lang.smalltalk.dolphin about the bad performance of
> this particular method in ST80. Unfortunately this is not easy to fix
> and there are a lot of edge cases to take care of, but by writing good
> tests it would be easy to find a better solution. John Brant suggested
> to use:
> Interval>>includes: aNumber
> aNumber isNumber
> ifFalse: [ ^ false ].
> self isEmpty
> ifTrue: [ ^ false ].
> (aNumber between: (start min: stop) and: (start max: stop))
> ifFalse: [ ^ false ].
> ^ step isInteger
> ifTrue: [ (aNumber - start) \\ step = 0 ]
> ifFalse: [ start + (step * ((aNumber - start) / step)
> rounded) =
> aNumber ].
> If the community is interested, I could submit the optimization
> including a bunch of tests to the mantis-archive for inclusion in 3.9?
> - It is not possible to atomically open a file locked, therefor this
> requires two operations that could potentially lead to race
> - We observed in some edge cases that a file was changed by a
> different image/process after having it locked. We don't know if this
> is OSProcess's, Squeak's or Unix's fault, but putting a short delay
> after sort of solved the problem, probably it is caused by some caches
> that are asynchronously flushed while or shortly after locking.
> - Another rather worrying observation is that OmniBase support for
> multiple concurrent images is explicitly unimplemented in VisualWorks,
> even-tough the product is sold as being able to support multiple
> images. My conclusion is that OmniBase probably never was tested,
> never used in production or never really worked for concurrent images
> accessing the same db.
> Lukas Renggli
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
More information about the Seaside