They call out to other library functions, which are better optimized
than the old naive implementations.
Add -fno-builtin to the musl strings Jamfile, otherwise GCC
generates infinite recursion in strcpy, apparently.
This allows us to gracefully fail if memory allocation fails,
rather than panic()ing. If a single-threaded application tries
to wait on a non-shared user_mutex in single-threaded mode, it
will now be dropped into the debugger.
This adds a new job to the Package Kit, and an invocation
in pkgman after changes are applied. The job takes a time_t before,
and an int32 minToKeep, and (after confirmation) deletes all state
directories which were last modified before that time, but also
keeps at least the minimum specified.
pkgman defaults to calling it with (now - 30 days, minimum 10).
SoftwareUpdater does the same, but without bothering the user
and just defaults to doing the cleanup.
Change-Id: I15f5232b11daba5955e7fa07f696ad7785507931
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10404
Reviewed-by: waddlesplash <[email protected]>
It doesn't refer to some random old state, but the currently active
one. (If the currently active state is the default one, then it will
return nothing.) So, this should make things clearer.
Change-Id: Ib3fe842f5fb51eaf2ef2f31bad8b292b47a3fb36
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10403
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
This header gets included in the build platform, so we can't use
the private recursive_lock.
Eliminates another statically created BLocker, due to gDefaultTokens.
This is not an expected failure condition for most applications,
so try to avoid propagating it to userspace.
(If necessary, it should be possible to avoid even the possibility
of this by just allocating necessary datastructures upfront
instead of "lazily". But that seems unnecessary at the moment.)
The lighter "struct mutex" is in a private header, so we can't
inline it in a public one, so just use pthread_mutex here.
By adjusting padding, the class size stays the same (72 bytes
on 32-bit, 96 bytes on 64-bit; confirmed via static_assert.)
A quick benchmark running "new/delete BMessage" in a loop on 4
threads at once goes from 30-36 seconds before this commit
to around 13-17 seconds, sometimes as low as 3 seconds, afterwards,
so clearly this is a significant improvement.
This also eliminates another BLocker allocated on application startup.
It seems in some applications (though not most of the ones I
initially tested) this can get used recursively, so we need
a recursive_lock in order to not deadlock.
Also commit a missed change from the previous commit.
X512 pointed out that ServerLink is inherited by PortLink which is
used by all windows, so the original change had the unintended effect
of allocating another semaphore for every window, which isn't wanted.
So, just use a static mutex here also.
The case where no BApplication has been created at the time of fork
is not blocked by this change (as it might be useful in fork-to-background
before creating a BApplication.)
Reinitializing or recreating a BApplication where one already exists,
though, is not supported by the kits, and just leads to problems.
And when the global destructors are invoked after a fork, such as by
exit(), then the parent team's state may be corrupted due to the
deletion of BLocker semaphores or other global state.
So, we thus set be_app to an invalid pointer, and if terminate_after()
is called with this pointer, we invoke debugger().
(We should really just prevent semaphores from being used across
processes unless explicitly specified, but that would be an
API compatibility break from BeOS, so we'll need to do it carefully,
or not until after R1.)
Would have clearly caught the problem in #18576 and the linked thread.
They don't work properly after a fork, and if exit() is called
from the forked child, the parent won't be able to use them
anymore.
In BBitmap and BPicture, replace them with mutexes. For AppServerLink,
make the private ServerLink inherit from BLocker, and then use
that one directly.
This also is a slight efficiency gain, as we don't need to create
multiple semaphores from the static initializers now, which is
just a waste of time in the case of applications that don't
even need these locks but link to libbe.so (e.g. CLI tools.)
Part of #18576.
This now does what notify_if_stat_changed used to, fixing a
race: if some thread was modifying a file, and some other thread
(or the same thread, in some other mtime-updating operation)
updated that file and this called MarkUnmodified() before the
first thread close()d it, then when the first thread called close(),
no node monitor notification would've been sent, as fModified
would've already been unset.
So, now every time we are to mark a file "unmodified", we also
send the node monitor notification at the same time.
Fixes the remainder of #19910.
This reverts commit 902921a554.
This broke resolution of CNAMEs, including the Haiku package repos.
Since pkgman uses our own HTTP implementation, which doesn't set
AI_V4MAPPED at all, this shouldn't have been a behavioral change for
it at all, much less having broken it.
Change-Id: If38b6a81c1144101ddea7d1f8d401326675479e3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10388
Reviewed-by: waddlesplash <[email protected]>
If a context switch happened between the messsage being
sent and received, we don't need to invalidate.
Brief testing on a 4-core VM shows this happens relatively
rarely during compile jobs (expected, most processes are
single-threaded), but very often while running multiprocess
web browsers. Some INVALIDATE_PAGES are skipped, but mostly
INVALIDATE_PAGE_LIST is (by the thousands.)
Change-Id: If32ed95139e0db3770054f6ef3f72c9aecb9394d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10350
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
This will be useful on architectures that support ASIDs, and on
ones that don't, it can be used to avoid a race between invalidation
messages being sent and context switches occurring on other CPUs.
In this commit, no behavioral change intended on any architecture.
Change-Id: I6d2ee4b69150f9ff8503329761266ddbdb550eab
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10349
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
This way we don't need to call barrier_unlock() in every thread
after exiting the wait loop, some syscalls. We can also avoid
spinning on the barrier mutex in "ensure_idle" (which is renamed
"ensure_none_exiting" for clarity), and instead lock it once and wait
for some thread to unblock all.
Overall, this strategy appears to be as much as 25% faster
than the previous, testing with pthread_barrier_test.
It seems the old design had at least one possible but very narrow
race in the "last one out" logic: if that thread was suspended
between the atomic_add() and the assignment of barrier->lock, and
all three other threads then ran past the add() in the next run,
then when the last-one-out woke up, it would clear the WAITING
flag spuriously.
This may help with #19876.
If we have no allocated swap space, then we don't need to even
bother doing a lookup in the hash table (which requires a read-lock,
anyway.)
This function is now called often even if swap isn't actively
being used, so any gains here are helpful.
Otherwise we might fail with B_NO_MEMORY, or wait for long periods of
time, which we don't want to do in such a critical routine.
Should improve system responsiveness (or even prevent application
crashes) under high memory pressure.
* Put each package on its own line. This mirrors the earlier
refactor of image rules.
* Drop a few packages with library-only provides. The build
system will pull them in automatically as needed (libicns, etc.)
The non-"_np" versions were exported, but not declared in the header.
Do that, and also make the "_np" versions the alias, as these are
specified in POSIX-2024.
... instead of GetIterator(). This allows us to avoid loading the
cache entirely in SetTo(), and allows consumers to read the cache
much more efficiently than loading it all into memory and then
freeing it again afterwards.
This technically breaks API/ABI, however the Package Kit APIs
are not considered stable (I don't think.)
All consumers adjusted. As we build the host tools with modern GCC
only, I made update_package_requires use a C++11 lambda function.
All others use out-of-line static methods.
"time pkgman list-repos -v" (which has to read the whole cache)
is ~0.5s before this change, and ~0.25s after this change,
on my test VM.
Change-Id: I6976b4cf5eb846fc925ed199dc00eb227fc81344
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10247
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
Reviewed-by: Andrew Lindesay <[email protected]>
POSIX-2024 says:
> There is no correlation between values of the st_blocks and
> st_blksize, and the f_bsize (from <sys/statvfs.h>) structure members.
Some code in Haiku has mixed that up in the past (e.g. the write_overlay).
This will allow a constant to be used instead, clarifying what's happening.
POSIX-2024 does not actually require this constant, but it does say:
> Traditionally, some implementations defined the multiplier for
> st_blocks in <sys/param.h> as the symbol DEV_BSIZE.
And indeed, glibc, musl, and FreeBSD (at least) all define it.
So it seems to make sense for us to do the same.
Related to #19251.
I added this assertion thinking it would incorrectly override
thread locales, and that invocationns this way would be a bug.
Instead it appears that this is the expected behavior in select
circumstances.
Fixes#19896 and other recent regressions.
* Drop the global definitions from ctype.h, and move them to
the internal LocaleData.h: the functions should be used always
when building new applications (as they're thread-safe.)
* Make __ctype_get_mb_cur_max thread-safe and move it to live
alongside the other __ctype...() methods.
* Put the __ctype...() methods in two files, clearly indicating
versions: ctype_loc_global for the global (non-thread-safe) versions,
used for the kernel, and ctype_loc_thread for the libroot versions.
* Consolidate more internal functions into LocaleInternal.cpp.
Just like O_NOFOLLOW. Also drop the now-redundant checks from
all filesystems.
At least some filesystem hooks (FIFOs in particular, see #19879) did not
check this, so this fixes them.
* get_new_fd is actually too late for the O_TRUNC one: we will
have already called the vnode open() hook by then. So, we
need to do that in open_vnode.
* Move checks to a new static helper method, and invoke it
in all relevant places.
* Delete now-redundant O_NOFOLLOW checks.
Specified in POSIX-2024.
GNUlib currently has a nasty Haiku-specific hack to implement
equivalent functionality; after this it should be able to use
this function instead.
Otherwise, calling open(O_CREAT) on a path that exists but is
a directory will succeed.
Fixes Sortix os-test open-tmpdir-rdonly-creat. (Interestingly
many other OSes also fail this test; only Linux, FreeBSD, Solaris,
and Sortix, and now also Haiku, properly return EISDIR.)
While at it, fix the doc comment, which appears to have been
copied from open_vnode.
These aren't actual limits, but rather the minimum limit
as specified in POSIX (e.g. _POSIX_NAME_MAX is the minimum
allowed value for NAME_MAX).
Add missing values as defined in POSIX-2024, at least for
features we support, and change wrong values to be the ones
specified in POSIX.
No behavioral intended change (nothing should be using these directly.)
It's specified in POSIX, and FreeBSD puts it in this file.
Distinguish it from _POSIX_SEM_VALUE_MAX (which is really a
"minimum value this can have" as specified in POSIX.)
We have returned "1" here since this code was originally written
in 2004 (hrev7290). BeOS R5 apparently returns "1000009" for this
value, while the Be Book gives no details about what this value means.
So, return an actually useful value of the Haiku version, and then
in uname() process this to return a string indicating the Haiku
version. This makes "uname" print the actual system version,
not just the hrev.
It appears Linux and other systems give non-integer values in
info->release, so this should be fine.
Fixes#17030.
It isn't working properly; see #19874.
Leave the others enable for testing for now. We can disable them
in the beta6 branch if necessary (if nobody reports that they are
indeed working.)
Augustin Cavalier