Update – we’re on a road to nowhere, come on inside…

Not much happening right now.

I ordered a PINE64 back in August as a 64-bit ARM platform. Instead of being posted to Germany, it was posted to the USA, where it’s gone in postal circles since then. I first emailed PINE about this about a month ago – they are now finally sorting it out.

It doesn’t matter much now in fact, because GCC 4.6.0 introduced a 128 bit type so I can use the GCC atomic intrinsics if you’re on that version of higher and get the built-in support for ARM64 double-word CAS. Still, it’ll be great to have another dev platform to actually test on.

I’ve been trying to get a mailing list going, A G A I N. Fourth or fifth try. Failed again. The problem is that almost all mailing list software uses CGI, which is not supported by nginx. Apache is a catastrophe – bloated and it turned out, very broken out of the box (default is IPv6 only and to deny all files), lighttpd is out of the question because it’s a thumping nightmare to configure. That left dadamail as a possible, since it can use FastCGI – and this ALMOST worked – but then it turns out dada uses wierd “cgi-name in the path with more path as arguments” and I could not face trying to configure that in the HTTP server, when it could just as well have used normal CGI arguments which would have worked exactly as well.

So I’m still stuck on this. I’m totally repelled by all the existing mailing list software I’ve seen (except for dadamail, which had a viable install path, but – as above – then takes a wrong turn) and for my simple use I can roll my own much more easily than trying to install an existing mailing list. The problem is I can’t easily get the HTTP server to operate the mailing list. I looked at the FastCGI spec, thinking to write one, and it’s a monstrosity. I’ve never seen something so simple be made so complicted, MY GOD.

I’ve more or less come to a halt with building all GCCs starting with 4.1.2, and matching glibcs, and using them for compiling and building. I spent five weeks on that, and in the end, I’m doing something wrong, because glibc fails to build with my compiler, and I am at a dead end. I can’t see what’s wrong – the problem is that a call to iconv seg faults. I’d still like to get this working, but… after five weeks and now being at a complete dead end with no clues, it’s not obvious what to do.

Once the mailing list is sorted out I can then get on with fixing the SMR design.

I’ve also now been closely reading Dreppers white paper about DSOs. I have a lot of changes to make, because of that.

Once SMR is up and Drepper-changes are done, then I need to figure out what’s happening with the performance of the unbounded/single/single queue and the freelist elimination layer, to implement and test the SMR based freelist, stack and unbouded/many/many queue, modify the ringbuffer to use the improvement in the queue with regard to queue element reuse (which will mean the ringbuffer elements retain physical locality between the ringbuffer element and its queue element), and then I can either release, or implement the full (not add-only) singly-linked list.