trws · HackerTrans

4 เดือนที่ผ่านมาdiscuss

Everything else in the siblings is true, but remember that the language and std types in rust all do this already. Most of the time it’s better to use a native enum or optional/result because they do this in the compiler/lib. It’s only really worth it if you need more than a few types or need precise control of the representation for C interop or something.

trws

4 เดือนที่ผ่านมาdiscuss

It’s Hana Dusikova’s paper IIRC.

trws

4 เดือนที่ผ่านมาdiscuss

There’s a paper in flight to add a stdlib type to handle pointer tagging as well while preserving pointer provenance and so-forth. It’s currently best to use the intptr types, but the goal is to make it so that an implementation can provide specializations based on what bits of a pointer are insignificant, or even ignored, on a given target without user code having to be specialized. Not sure where it has landed since discussion in SG1 but seemed like a good idea.

trws

8 เดือนที่ผ่านมาdiscuss

I worked @fzakaria on developing that idea. It actually worked surprisingly well. The benefits are mostly in the ability to analyze the binary afterward though rather than any measurable benefit in load time or anything like that though. I don’t have the repo for the musl-based loader handy, but here’s the one for the virtual table plugin for SQLite to read from raw ELF files: https://github.com/fzakaria/sqlelf

trws

10 เดือนที่ผ่านมาdiscuss

I liked the article. I saw your PS that we added it to the working draft for c++26, we also made it part of OpenMP as of 5.0 I think. It’s sometimes a hardware atomic like on arm, but what made the case was that it’s common to implement it sub-optimally even on x86 or LL-SC architectures. Often the generic cas loop gets used, like in your lambda example, but it lacks an early cutout since you can ignore any input value that’s on the wrong side of the op by doing a cheap atomic read or just cutting out of the loop after the first failed CAS if the read back shows it can’t matter. Also can benefit from using slightly different memory orders than the default on architectures like ppc64. It’s a surprisingly useful op to support that way.

If this kind of thing floats your boat, you might be interested in the non-reading variants of these as well. Mostly for things like add, max, etc but some recent architectures actually offer alternate operations to skip the read-back. The paper calls them “atomic reduction operations” https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p31...

trws

10 เดือนที่ผ่านมาdiscuss

Quite so. We would have too, but I left out the nasty bit that someone had at one point put a callback argument in an internal launching API that runs between fork and exec. Still working on squashing the last of those.

trws

10 เดือนที่ผ่านมาdiscuss

The other place it comes up is launchers and resource managers. We actually have a series of old issues and implementation work on flux (large scale resource manager for clusters) working around fork becoming a significant bottleneck in parallel launch. IIRC it showed up when we had ~1gb of memory in use and needed to spawn between 64 and 192 processes per node. That said, we actually didn’t pivot to vfork, we pivoted to posix_spawn for all but the case where we have to change working directory (had to support old glibc without the attr for that in spawn). If you’re interested I think we did some benchmarking with public results I could dredge up.

Anyway, much as I have cases where it matters I guess what I’m saying is I think you’re right that vfork is rarely actually necessary, especially since you’d probably have a much easier time getting a faster and still deterministic spawn if it ever actually becomes a bottleneck for something you care about.

trws

11 เดือนที่ผ่านมาdiscuss

You have this largely right, but I need to defend the Radeon driver a bit here. The driver that caused all the problems was the proprietary fglrx driver, not the open source Radeon driver. The issue with the Radeon driver wasn’t stability, it was that it was 2d acceleration only.

trws

ปีที่แล้วdiscuss

I just started giving it a try again about a week ago, and I second this. A year ago it was nearly unusable for any extension outside their preferred list, now it’s largely a pleasant experience.

trws

3 ปีที่แล้วdiscuss

Oh that’s pretty cool, thanks for the link. I’ve used davmail as a proxy like this, just for the oauth support, but it doesn’t scale to large mailboxes or high traffic well at all. May forward this along for some of our internal services people.

trws

3 ปีที่แล้วdiscuss

Sadly you’re right. Microsoft has brainwashed many IT departments into forcing oauth on everything, no app specific passwords, no regular passwords, nothing else. Thankfully they do support this on imap and smtp, but you have to have something that can handle it. I use a modified version of isync with the sasl plugin to fetch mail, and a python smtp sender that supports the oauth flow along with a set of scripts for generating a new refresh token every few months. It’s a heck of a lot of stuff to maintain, but at least it works. If anyone’s interested I could provide links or upload the modified versions to fix o365 quirks.

comments