I always knew AirBnB was weird.

Now I really know.

If I *MOVE THE MAP*, the pricing of an apartment changes, from 1147 to 1151.

In other news, I believe one of my grandparents was Irish and so through him I will be able to claim Irisih citizenship, which will get me back in the EU, thank Christ.

I’ve not touched the library for a bit – been making a web-site for a friend.

My current thought is to get bsearch and qsort out of test, so it’s bare C89 (plus threads) and get SMR in and debugged (and maybe also an add+delete singly linked list). The unbounded single/single queue is in already. Then publish 7.2.0.

unbounded, single/single queue implemented

Seems to work.

Tests pass. Need to do more test though.

It’s the M&S queue, with atomics removed, and it’s “odd” in that although the dequeuer gets key/value pairs as he dequeues, it’s actually the enqueue thread which gets the dequeued queue elements out of the queue for reuse/free (when you call enqueue, or if you explicitly flush – there’s a function call for it) the emptied (i.e. dequeued) queue elements, which are at that point still in the queue, come back to the user via a callback).

Samba update is blocking

I’ve issued a full package upgrade of my Linux system through Synaptic Package Manager.

It’s been taking a LONG time.

Eventually, I go over to it and expand the “details” option.

The (supposedly) automated Samba installer displays a help text which requires the user to scroll to the end and hit “q”. It’s blocked tne entire update process.


Unbounded, single producer, single consumer queue idea

Chatting with a friend online about queue use and an idea struct me.

There is a well known bounded single producer single consumer queue. The Linux kernel uses it, there’s an implementation in liblfds.

I think thought it should be possible to make an unbounded single producer single consumer queue.

What’s odd about it is that the writer thread is the thread which is responsible for removing dequeued elements from the queue.

So we have a normal looking queue, elements with next pointers, an enqueue and a dequeue pointer.

The reader thread, once it’s done with an element, marks the element as read – it is however the only write to that flag. The writer is the only reader from that flag.

So we imagine the queue is empty, enqueue and dequeue both NULL. Writer writes; he is given an element (no memory allocations, remember), he sets the user data, sets next to NULL, store barrier, modifies the dequeue pointer.

Reader thread later comes to read, we assume the writes have propogated (we’ll see the user data first, so we’re safe), we read the dequeue pointer, get the element, get the user data, now set the “done with it” flag.

The writer when he nexts writes adds the element as before, but also scans from the dequeue pointer, finding dequeued elements and unlinking them.

Have to work through all the details to see if it can work.

Mediawiki / Firefox hell

I’m finally fixing up the “White Papers” page on the wiki.

It is, frankly, a descent into hell.

The problem is that the filenames for the white papers are like this;

[Counter] – [Aspnes, Herlihy, Shavit] – Counting Networks.pdf

See those square backets? and the spaces?

It’s like I’ve just tapped directly into every combined neurotic design flaw of Medawiki and Firefox.

Mediawiki can’t have square brackes in URLs, or spaces. Okay, I’ll URL encode. Doesn’t work. Mediakwiki does not recognize a URL encoded string as a URL – not unless it begins with the “http://” – *unencoded*.

Firefox doesn’t recognize either the fully encoded URL, or the bastardized version beginning with “http://”.

It turns out that URL encoding seems to have changed?

Using http://meyerweb.com/eric/tools/dencoder/ gives this;


It doesn’t work. Paste that into Firefox and it’ll *prepend* “http://” (FOR CHRISTS SAKE DON’T DO THAT) and then tell you it can’t find the server “http%3A%2F%2Fwww.liblfds.org%2Fdownloads%2Fwhite%20papers%2F%5BCounter%5D%20-%20%5BAspnes%2C%20Herlihy%2C%20Shavit%5D%20-%20Counting%20Networks.pdf”. Genius. *facepalm*.

Bastardizing it in the way Medaiwiki requires (unencoded “http://”) makes no difference.

However, I guessed that if I enter the original unencoded URL into Firefox, if I copy’n’pasted from its URL bar I’d get the encoded version – and I do, which is also FACEPALM, because what you’re SEEING is not what you’re GETTING. WRONG.

So Firefox gives me this;


Firefox seems to not encode the path, not encode commas, but does encode square brackets and spaces.

So, like, what the HELL? I thought URL encoding was URL encoding. All the reserved characters became percent encoded and that was it.

So, like, what the hell is going on? Multiple variants of URL encoding? the HELL? if that’s so, can you imagine anything more likely to lead to disaster?

So it’s taken an hour *to get a link working in a mediawiki page*. I’m also wondering if it’ll even work in other browsers. Maybe Firefox has it’s own unique bizzare version of URL encoding.