We want them for the heap buffers, but the rest will generally only
be used when other packagefs locks are acquired (during mounting
or unmounting of packages), so the depots are just a waste.
* This is the closest thing ARM has the semantics of write-combining
MTR on x86.
Change-Id: I12a1582e0af871e2ab729262e90695ffe928c85b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8223
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* This fixes arm64 where disabling caching also disables
unaligned accesses.
* This matches how FreeBSD implements this callback.
Change-Id: Iee081d4ecff05b05c3758502d0cdacfbc56b11d8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8191
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
According to the POSIX specification:
> The sem_timedwait() function shall fail if:
> [EINVAL]
> The process or thread would have blocked, and the abstime
> parameter specified a nanoseconds field value less than zero
> or greater than or equal to 1000 million.
Fixes #16693, #16694.
Haiku's Be-style semaphores have a global limit, but the
POSIX-style semaphores do not. Functionally there will be a limit
as to how many can be waited on at a time, but one will probably
hit thread limits before that happens.
This matches what FreeBSD does: specifies 256 for _POSIX_SEM_NSEMS_MAX
but then returns -1 for the sysconf value.
Fixes #16692.
If a multibyte Unicode character is specified to MultibyteToWchar
one byte at a time, then resetting the state will lose the data
for the second character. We thus shouldn't re-read but instead
keep the existing character and just read the second one.
Fixes #19035.
Otherwise, when the current locale timezone is one that has
an offset to GMT of 0, we would wind up with its name in tm_zone
and not "GMT".
Follows up to #19047.
We can be called with a timezone that isn't the same as the one
set in the current locale, in particular from gmtime(). We thus need
to handle this case properly by checking that the gmtoff is really
the timezone in the locale, or if it's GMT, to just use a static
string for the tm_zone instead.
Fixes #19047.
-1 was our previous value for AT_FDCWD, so we should retain support
for it here for the moment. All other negative values will now result
in an error.
Part of #19048.
The local transferEndOffset should be relative to the parent (us),
not to the underlying filesystem. We thus need to subtract our
own offset from the operation's offset.
This fixes a regression from be8080575a5ae9e8ecba3494afdd081cb4fd94a2.
Errors transferring data should now be properly reported in more cases.
i.e. not on Deskbar team menu, menu field menus or the clock
options menu but all regular menus at the top of the window
and other context-click menus.
Change-Id: If551aecd040500973a92fda2138b6ffe03cda279
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8154
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: John Scipione <jscipione@gmail.com>
Some things that call these macros put expressions in them; to avoid
operator precedence problems we should put them in parens.
Change-Id: I57335ffb190c484778c4bc8075d5ca3597f1e7e5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8184
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Lookups are more frequent than cache deletions.
Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
A compile benchmark seems to have little if any performance improvement.
However, this codepath will be hit when allocating pages that are
cached, so it may provide a more significant improvement once file
caches are fully utilized.
Implemented using __builtin_clz where available, otherwise using
an algorithm derived from "Bit Twiddling Hacks" which is similar
to the one ramfs uses. GCC and Clang seem to unroll the loop on
x86 at least (but it doesn't matter there as the builtin exists,
implemented using the "bsr" instruction.)
After settings Backgrounds to None for all worskapces, I was getting a 100%
reproducible segment violation on "fShowingBitmap->fBitmap->Bounds()" with every
resolution change.
Change-Id: I2a3640a3c33e571d772c1b38b21087346215dca8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8176
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
... whatever motivated this to only work on disabled text views
has been resolved.
Change-Id: I3ae9d056870f1163d3fa074ab9a1dad96c0192f8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8168
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
