RecursiveLock in the kernel.
* Several adjustments according to UserlandFS header changes.
* Re-added reiserfs to image.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29410 a95241bf-73f2-0310-859d-f6bbb57e9c96
new thread and the main thread in this order. Allows to reproduce #2956
quite often.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29301 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Refactored hard-coded group insets.
* Geve second tab BView the standard gray background.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29213 a95241bf-73f2-0310-859d-f6bbb57e9c96
assumption, that the program image is ignored when relocating symbols of
dlopen()ed objects, is incorrect.
* Adjusted the tests that were failing due to that.
* The RTLD_NEXT test also fails with openSuse 10.3 -- apparently the semantics
has changed between the Linux versions.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29111 a95241bf-73f2-0310-859d-f6bbb57e9c96
layout version of that class. (drawing artefacts, wrong scrollbar placement)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29098 a95241bf-73f2-0310-859d-f6bbb57e9c96
it to the test app. This finally fixes ticket #2594.
* Of course, I neither saw this one before, nor did I accidently reproduce it
with a test :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28967 a95241bf-73f2-0310-859d-f6bbb57e9c96
previous release of BufferQueue. IOW #2594 should be fixed now.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28943 a95241bf-73f2-0310-859d-f6bbb57e9c96
or moving mode when it was shown again. Added a test app HideAndShow which let
you easily reproduce the faulty behaviour (with a previous version of the
app_server, that is).
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28847 a95241bf-73f2-0310-859d-f6bbb57e9c96
to succeed on Linux. FreeBSD fails some tests since it seems to have a
different load order (depth-first instead of breadth-first). Haiku fails
a lot of tests due to its POSIX non-compliant dlopen().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28556 a95241bf-73f2-0310-859d-f6bbb57e9c96
discarded blocks correctly as well.
* cache_detach_sub_transaction() left cached_block::original_data unchanged even
if the parent data was to become current (in case the sub transaction didn't
change the block yet). This could cause outdated blocks to be written back.
* cache_detach_sub_transaction() also set cached_block::previous_transaction
for all blocks, not just the ones with a previous transaction. This could
cause blocks to be written twice for no reason.
* cache_start_sub_transaction() did not change the num_blocks count for
discarded blocks.
* block_cache_discard() now panics if the block was already changed in the
current transaction.
* Improved test application, added more tests, revealing the above bugs in
cache_detach_sub_transaction().
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28514 a95241bf-73f2-0310-859d-f6bbb57e9c96
cache_end_transaction(), and cache_start_sub_transaction()).
* Further work on the test application, it's now actually usable, first test
passes.
* dump_block() did erroneously print 'B' for the dirty flag; now both dirty and
discard have the 'D' (3rd and 5th column).
* block_cache::LowMemoryHandler() is now private (and got an underscore prefix).
* Minor cleanup, shuffled some methods around.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28508 a95241bf-73f2-0310-859d-f6bbb57e9c96
discarding their changes. This functionality currently only works correctly
when no transactions are used.
* Started test application for the block cache, doesn't do anything yet.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28496 a95241bf-73f2-0310-859d-f6bbb57e9c96
random SHA hashes.
* Moved AdaptiveBuffering into its own file.
* Fixed updating a hash file.
* Implemented the "consistency_check" app that checks if a file has changed,
and prints warnings if there are any.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28419 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Unfortunately, there still seems to be a problem in the hash generation...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28412 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Started a file consistency checker; right now, it will just compute a SHA256
hash value for every file, and dump it to stdout.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28406 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Also renamed it to random_read, but SVN needs two revisions for that...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28400 a95241bf-73f2-0310-859d-f6bbb57e9c96
fixes in my tree to make it compile on R5 still. I don't really want to
check this in, I'd rather adopt the buildsystem to make it run on Haiku
itself...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28298 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Made the StressTest app into a real stress test for the app_server, as the
windows are now randomly changed, ie. moved, resized, hidden, activated, ...
* This already helped identifying two long-hiding bugs in the app_server code!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28216 a95241bf-73f2-0310-859d-f6bbb57e9c96
something (as reported by Marcus and Bruno on the mailing list).
* AllocationGroup::Allocate() would always invalidate the largest block if
it did not cover the largest part of the group; now it only invalidates it
if it has been cut before.
* Added small test app for the invalidation part.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28162 a95241bf-73f2-0310-859d-f6bbb57e9c96
shows a bug in the app_server event dispatching which is going to be fixed
next.)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28058 a95241bf-73f2-0310-859d-f6bbb57e9c96
