advice for implementing an atomics wrapper
Hi, For mongodb 8.0 I need to give a FreeBSD implementation of this file. https://github.com/mongodb/mongo/blob/master/src/mongo/platform/waitable_atomic.cpp Using the __Apple__ definition gives: ld.lld: error: undefined symbol: __ulock_wake ld.lld: error: undefined symbol: __ulock_wait And the __linux__ definition uses futex which FreeBSD does not have AFAIK. What is an easy way to port this file? Regards, Ronald.
Re: advice for implementing an atomics wrapper
Sorry, Something broke the pasted URL. https://github.com/mongodb/mongo/blob/master/src/mongo/platform/waitable_atomic.cpp Another attempt. Ronald. Van: Ronald Klop Datum: dinsdag, 23 juli 2024 16:14 Aan: freebsd-po...@freebsd.org Onderwerp: advice for implementing an atomics wrapper Hi, For mongodb 8.0 I need to give a FreeBSD implementation of this file. https://github.com/mongodb/mongo/blob/master/src/mongo/platform/waitable_atomic.cpp Using the __Apple__ definition gives: ld.lld: error: undefined symbol: __ulock_wake ld.lld: error: undefined symbol: __ulock_wait And the __linux__ definition uses futex which FreeBSD does not have AFAIK. What is an easy way to port this file? Regards, Ronald.
Re: advice for implementing an atomics wrapper
Hi,
The __APPLE__ implementation also pointed to the implementation in that file
and I used it to come up with a patch.
#elif defined(__FreeBSD__)
void notifyOne(const void* uaddr) {
_umtx_op(const_cast(uaddr), UMTX_OP_WAKE, 1, NULL, NULL);
}
void notifyMany(const void* uaddr, int nToWake) {
_umtx_op(const_cast(uaddr), UMTX_OP_WAKE, nToWake, NULL, NULL);
}
void notifyAll(const void* uaddr) {
_umtx_op(const_cast(uaddr), UMTX_OP_WAKE, INT_MAX, NULL, NULL);
}
bool waitUntil(const void* uaddr,
uint32_t old,
boost::optional deadline) {
struct timespec timeout;
bool timeoutOverflow = false;
if (deadline) {
int64_t micros = durationCount(*deadline -
system_clock::now());
if (micros <= 0) {
return false; // Synthesize a timeout.
}
if (micros > int64_t(std::numeric_limits::max())) {
// 2**32 micros is a little over an hour. If this happens, we wait
as long as we can,
// then return as-if a spurious wakeup happened, rather than a
timeout. This will cause
// the caller to loop and we will compute a smaller time each pass,
eventually reaching
// a representable timeout.
micros = std::numeric_limits::max();
timeoutOverflow = true;
}
timeout.tv_sec = micros / 1000;
timeout.tv_nsec = (micros % 1000) * 1000;
}
if (_umtx_op(const_cast(uaddr), UMTX_OP_WAIT, old, (void*)sizeof(struct
timespec), &timeout) != -1)
return true;
// There isn't a good list of possible errors, so assuming that anything
other than a timeout
// error is a possible spurious wakeup.
return timeoutOverflow || errno != ETIMEDOUT;
}
It compiles and runs in my simple tests (although I don't know if my simple
tests execute this part of mongodb code). Suggestions are of course welcome.
Regards,
Ronald.
Van: Michael Gmelin
Datum: dinsdag, 23 juli 2024 17:32
Aan: Ronald Klop
Onderwerp: Re: advice for implementing an atomics wrapper
Does this help?
https://reviews.llvm.org/D142134
On 23. Jul 2024, at 16:17, Ronald Klop wrote:
>
Sorry,
Something broke the pasted URL.
https://github.com/mongodb/mongo/blob/master/src/mongo/platform/waitable_atomic.cpp
Another attempt.
Ronald.
Van: Ronald Klop
Datum: dinsdag, 23 juli 2024 16:14
Aan: freebsd-po...@freebsd.org
Onderwerp: advice for implementing an atomics wrapper
Hi,
For mongodb 8.0 I need to give a FreeBSD implementation of this file.
https://github.com/mongodb/mongo/blob/master/src/mongo/platform/waitable_atomic.cpp
Using the __Apple__ definition gives:
ld.lld: error: undefined symbol: __ulock_wake
ld.lld: error: undefined symbol: __ulock_wait
And the __linux__ definition uses futex which FreeBSD does not have AFAIK.
What is an easy way to port this file?
Regards,
Ronald.
Re: Porting a new Golang app: go mod replace relative path
Excellent thank you. There has been a new version and I'd like to update soon. I'll pr and send an email next time. Btw, there is a bug for this new port. El mar, 23 de jul de 2024, 05:34, Matthias Fechner escribió: > Am 24.04.2024 um 18:26 schrieb Zach Leslie: > >> maybe by an additional manually added distfile entry to place it in the > >> expected directly (maybe in a prefetch rule or by just manually > extending > >> the DIST_FILES). > > Thank you for the pointers. I was able to get something working and > > have submitted the following pull request for this new port. > > > > https://github.com/freebsd/freebsd-ports/pull/252 > > > I commited it, thanks for your contribution. > I you add github pull requests, make sure you always write to an email > list, as most of the committers work with the official bug tracker, but > they maybe do not monitor github. > > Gruß > Matthias > > -- > > "Programming today is a race between software engineers striving to > build bigger and better idiot-proof programs, and the universe trying to > produce bigger and better idiots. So far, the universe is winning." -- > Rich Cook > >
Re: Porting a new Golang app: go mod replace relative path
I'm on mobile, but #279042 was filed. El mar, 23 de jul de 2024, 17:35, Zach Leslie escribió: > Excellent thank you. There has been a new version and I'd like to update > soon. I'll pr and send an email next time. Btw, there is a bug for this > new port. > > El mar, 23 de jul de 2024, 05:34, Matthias Fechner > escribió: > >> Am 24.04.2024 um 18:26 schrieb Zach Leslie: >> >> maybe by an additional manually added distfile entry to place it in the >> >> expected directly (maybe in a prefetch rule or by just manually >> extending >> >> the DIST_FILES). >> > Thank you for the pointers. I was able to get something working and >> > have submitted the following pull request for this new port. >> > >> > https://github.com/freebsd/freebsd-ports/pull/252 >> > >> I commited it, thanks for your contribution. >> I you add github pull requests, make sure you always write to an email >> list, as most of the committers work with the official bug tracker, but >> they maybe do not monitor github. >> >> Gruß >> Matthias >> >> -- >> >> "Programming today is a race between software engineers striving to >> build bigger and better idiot-proof programs, and the universe trying to >> produce bigger and better idiots. So far, the universe is winning." -- >> Rich Cook >> >>
Re: Porting a new Golang app: go mod replace relative path
I have made some updates to the PR. Please advise if I should open a new PR to address the feedback. El mar, 23 de jul de 2024, 17:36, Zach Leslie escribió: > I'm on mobile, but #279042 was filed. > > El mar, 23 de jul de 2024, 17:35, Zach Leslie > escribió: > >> Excellent thank you. There has been a new version and I'd like to update >> soon. I'll pr and send an email next time. Btw, there is a bug for this >> new port. >> >> El mar, 23 de jul de 2024, 05:34, Matthias Fechner >> escribió: >> >>> Am 24.04.2024 um 18:26 schrieb Zach Leslie: >>> >> maybe by an additional manually added distfile entry to place it in >>> the >>> >> expected directly (maybe in a prefetch rule or by just manually >>> extending >>> >> the DIST_FILES). >>> > Thank you for the pointers. I was able to get something working and >>> > have submitted the following pull request for this new port. >>> > >>> > https://github.com/freebsd/freebsd-ports/pull/252 >>> > >>> I commited it, thanks for your contribution. >>> I you add github pull requests, make sure you always write to an email >>> list, as most of the committers work with the official bug tracker, but >>> they maybe do not monitor github. >>> >>> Gruß >>> Matthias >>> >>> -- >>> >>> "Programming today is a race between software engineers striving to >>> build bigger and better idiot-proof programs, and the universe trying to >>> produce bigger and better idiots. So far, the universe is winning." -- >>> Rich Cook >>> >>>
Committer wanted for step-certificates and step-cli update to 0.27.2
Hi all, Could a committer please commit: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280419 and https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280420 Both have been tested successfully in my local poudriere. Thanks in advance Markus
Unmaintained FreeBSD ports which are out of date
Dear port maintainers, The portscout new distfile checker has detected that one or more unmaintained ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. Please consider also adopting this port. If any ports have already been updated, you can safely ignore the entry. An e-mail will not be sent again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ audio/baresip | 3.13.0 | v3.14.0 +-+ audio/re| 3.13.0 | v3.14.0 +-+ devel/py-archinfo | 9.0.5405| v9.2.112 +-+ devel/py-cle| 9.0.5405| v9.2.112 +-+ math/py-claripy | 9.0.5405| v9.2.112 +-+ security/py-ailment | 9.0.5405| v9.2.112 +-+ security/py-angr| 9.0.5405| v9.2.112 +-+ security/py-pyvex | 9.0.5405| v9.2.112 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Reported by:portscout!
