kqueue: compare against the size in kqueue_expand
This is a cosmetic change, rather than a functional one: comparing the
knlistsize against the fd requires a little bit of mental gymnastics to
confirm that this is fine and not doing unnecessary work in some cases.
Notably, one must consider that kq_knlistsize only grows in KQEXTENT
chunks, which means that concurrent threads trying to grow the kqueue
to consecutive fds will usually not result in the list being replaced
twice. One can also more clearly rule out classes of arithmetic
problems in the final `else` branch.
Reviewed by: kib, markj
Differential Revision: https://reviews.freebsd.org/D56209
kqueue: add some kn_knlist assertions around knlist_(add|remove)
We currently assert that kn_status is accurate, but there's more room
for error. Neither of these are very likely, but currently we'd blow up
in SLIST*() macros instead of providing more obvious diagnostics. It's
perhaps only worth testing these because knlist_remove() requires
getting logic across both f_attach() and f_detach() correct.
Reviewed by: kib, markj
Differential Revision: https://reviews.freebsd.org/D56211
kqueue: simplify knote_fdclose()
The influx logic in knote_fdclose() is a little misguided, the resulting
wakeup() call should always be redundant: knote_drop_detached() will
always issue a wakeup before it returns, so anything waiting on *that*
knote that had entered fluxwait should have been woken up then. This is
the obvious divergence from the other influx/wakeup pattern in the
implementation, which will kn_influx-- and then issue the wakeup after
it has processed all of the knotes it can make progress on.
While we're here, the kq_knlist cannot shrink, so we can avoid that
condition in the loop and avoid potentially excessive wakeups from
fluxwait on kqueues that we didn't touch.
Reviewed by: kib, markj
Differential Revision: https://reviews.freebsd.org/D56210
kqueue: avoid a possible fork-deadlock
kqueue_fork_copy() is likely to have transitioned at least one knote
through a flux state, so we should check whether we need to wake
anything up on the way out to avoid a possible deadlock.
This was a part of D56210, but we'll close the review with the next
commit.
Fixes: b11289f87123f ("kqueuex(2): add KQUEUE_CPONFORK")
Reviewed by: kib, markj
compat/linux: map TCP_USER_TIMEOUT sockopt into TCP_MAXUNACKTIME
After reading both manual pages, our TCP_MAXUNACKTIME is fairly
similar to the TCP_USER_TIMEOUT, the only considerable difference
is ours is in seconds and linux's in milliseconds.
Round up linux's in setsockopt(2) to a next whole second and
clamp ours getter to UINT_MAX ms.
Reviewed by: tuexen, glebius
Differential Revision: https://reviews.freebsd.org/D56168
MFC after: 2 weeks
Sponsored by: Sippy Software, Inc.
games/libretro-shaders-glsl: Update to g20260330 and adopt port
* Adopt port
* Update COMMENT and pkg-descr to point out that the shaders originate
from the libretro project, but that they can also be used by other
projects, e.g. ScummVM.
* Use short hash for GH_TAGNAME. This follows the Porter's Handbook more
closely.
* Set DATADIR to its actual non-standard directory.
* The shaders are architecture-independend and there's nothing to build,
so set NO_ARCH and NO_BUILD.
* Use COPYTREE_SHARE for installing to ensure proper file ownership and
permissions, and to not require the make binary. In this case do not
extract unneeded build and CI files by excluding them via
EXTRACT_AFTER_ARGS.
* Remove obsolete Makefile patch.
Changelog:
https://github.com/libretro/glsl-shaders/compare/e66776c...bf52cc8
[2 lines not shown]
www/py-hyperkitty: Add rc.d script for mailman-qcluster
* Add sysrc script for mailman-qcluster
To improve performance, HyperKitty uses a distributed task queue
that offloads long operations to separate processes called “workers”
* Add pkg-message
PR: 292013
Approved by: Einar Bjarni Halldórsson <einar at isnic.is> (maintainer)
Approved by: yuri@ (Mentor)
