Has anyone seen performance measurements for hardware lock elision? What's the performance gain/loss in the uncontended case? How costly is an aborted transaction?
Well I am probably going to be shot down here. glibc has all the basics down. And its on every Linux (and other OSes) box. How about letting fopen() open a URL? It would be great if any *nix code could do that. There already a a bunch of sorts qsort(), heapsort(), etc. But there isn't a sort for huge array using disk or mapped memory (that I know of). How about making qsort() work differently based on an environment variable? OK fire away.
Well, the big problem here is that glibc isn't on every other OSes box. FreeBSD uses its own libc, as does Solaris, HP-UX, AIX, etc. In fact, the latter three are probably more in common with each other than with glibc. And certainly the CRT on Windows is a different beast entirely.
Personally, I want a predictable API between different libc versions; I don't want to deal with somebody's code that assumed that they could fopen(3) a URL and have it do something useful. That Solaris and Linux (say) set errno slightly differently for the same error is enough for me to pull my hair out.
And yes, I realize I brought Windows into this argument, but at least you know that Windows is always going to be a little bit different, whereas you expect all the Unix libc implementations to act mostly the same way for most of the things, even though in your cold, cynical heart you realize that's idealistic.
But my cold, cynical heart is still idealistic and believes that all fopen(3) should be fopen(3) everywhere. So if you can get all of the vendors on board, then let's talk.
