mipsel arch lacks AtomicU64 support about fish-shell HOT 5 CLOSED

Could you consider using AtomicUsize in these places?

In a bunch of places we can use it or just direct AtomicU32 instead (not sure which is better).

For instance the "RUN_COUNT" and "STATUS_COUNT" variables here are really just "has this changed" flags - we only increment them and check if they are != to some stored value.

For others, it's not as easy - we store the process status as an AtomicU64, which is really just two variables packed into it, and one of which is a bool and one of which comes from the OS as a c_int - which is an i32.

It's possible to change this, but it would be work and change the ergonomics a bit.

To be honest, given that the affected architectures really just are 32-bit mips(/el) and PowerPC I'm not sure that's worth it. Note that Debian stopped the mipsel port last year and the 32-bit PowerPC port with version 9 (released 2017, official support ended in 2020 - there was an LTS but not for these arches).

from fish-shell.

Lack of AtomicU64 by itself is not a reason to drop a platform, we can surely take a patch to work around that (or you maintain it dowstream if it's an experimental/short-term thing).
What is more worrying is that it sounds like the reader is dysfunctional. If someone is interested in fixing that, by all means

from fish-shell.

What is more worrying is that it sounds like the reader is dysfunctional

Note that this was a sed-patch that changed "AtomicU64" to AtomicU32, while we pass them as u64 without the atomic.

It will also entirely break the ProcStatus type by removing half the bits.

This isn't a full patch and so things not working doesn't by itself mean much.

we can surely take a patch to work around that

How about this: If someone proposes a usable patch until the next release cool, if not tough luck.

from fish-shell.

I think this should be patched in a fork or in the distribution package. AtomicU64 should be replaced with a newtype containing a u64 and a mutex. On our end, anything that doesn't actually use all 64 bits can certainly be shrunk (probably just things that should be an AtomicBool to begin with).

What is more worrying is that it sounds like the reader is dysfunctional. If someone is interested in fixing that, by all means

If bits are randomly discarded, that isn't surprising.

from fish-shell.

thanks everyone for your inputs, and the works to port to pure-rust as much as feasible.

I see that bringing back mipsel support is not worth it upstream, due to burden on other popular platforms. I would try to downsize the smaller usages on x86_64 and submit if applicable, and then do proper Mutex<u64> inside a bookworm container locally. nightly with -Zbuild-std helps simulating openwrt builder.

Sorry about bringing up the reader freeze, and muddied the point.

from fish-shell.