Why can't it work? You need to assume that the C library is only ever passed well-behaved pointers and callbacks in order to avoid invoking UB that it can't know about - but other than that it's just a matter of marshaling from the usual C ABI to the Fil-C ABI, which should be doable.

▲

testdelacc1 3 days ago | parent [-]

I’m assuming the calling program is a GC language like Python or Node (the most popular run times by far), but the same holds with other popular languages like Ruby. Why would a GC language call out to slow code, that runs its own separate GC. Now you have two GCs running, neither of which knows about the other. I’m not declaring it’s impossible, I’m asking why someone would want to do this.

An example: GitHub’s entire business revolves around calling libgit2 (C) from Ruby. Are they more likely to slow down libgit2 and make it substantially more complex by running 2 GCs side by side, or are they going to risk accept any potential unsafety in regular C? It’s 100% the latter, I’ll bet on that.

▲

zozbot234 3 days ago | parent | next [-]

> ...Now you have two GCs running, neither of which knows about the other. ...

For a strictly time-limited interaction (like what's involved in a FFI call) it's not that bad. Everything that GC2 might directly access is temporarily promoted to a root for GC1, and vice versa.

▲

gf000 2 days ago | parent | prev | next [-]

A native library is an obvious memory safety hole so I don't see why would it be that controversial to want to fill it even if it introduces another GC (but working on an independent heap, so the slowdown is not necessarily multiplicative)

▲

actionfromafar 3 days ago | parent | prev [-]

The former could still be cheaper than stop using libgit altogether.

▲

testdelacc1 3 days ago | parent [-]

No one is asking them to stop using libgit2 though. They’re going to continue using it. If they find a serious bug, they’ll fix it and continue using it.

The cost of all the additional hardware is just not worth it. If it was a choice between higher hardware costs, higher request latency, greater operational complexity of a new technology and rewriting libgit2 in a different language without all those tradeoffs, GitHub definitely chooses the latter.

But it’s never going to reach that point because they’ll continue using libgit2 compiled by clang forever.

	▲	actionfromafar 3 days ago \| parent [-]
		That's very interesting to learn.