This morning I saw that iTerm had been forked and someone was working on it again. It's been stale for quite a while, and with the additions to Mac's Terminal.app, there's reason to believe they just stopped work on it. But others picked up the torch.
I like the changes they have made in the fork, and we'll see how it goes in the coming weeks. But good enough. Gotta love the open source possibilities.
Today I wanted to just build a conflation queue and integrate it into a few of my endpoints in the message flow so that slow consumers, or very fast producers, don't overwhelm the system. It's a simple design: a queue with a map that are linked so that the map can quickly tell the insert routine if the message already exists in the queue, and so just the contents are replaced. It's standard stuff, but there are always a few tricks.
In my case, I wanted to have the uniqueness of the messages dictated by the type, and unsigned 8-bit integer, and a conflation key, a 64-bit unsigned integer that is returned by each message indicating the uniqueness of the message within that family of message. I decided to use a simple STL std::pair as it could be used in the std::deque as well as the std::map as a key.
When I got into the code, though, I realized that there were plenty of places I wasn't doing any kind of buffering - specifically, the TCP endpoints. So I had to go into those components and put in a simple byte-level buffer with an additional thread for de-spooling. That took time. Then I saw that there were a few more that needed some work, and pretty soon the entire morning was gone.
Finally, though, I got all the components working and testing just fine - which wasn't as easy as it used to be with additional threads running around. In fact, it was a mess of segmentation faults until I changed the way I was terminating the unspooling threads. But I got it all going.
The afternoon was devoted to getting the conflation queue working and tested out. It's nice, and it should be pretty fast, but I'll have to wait and see how it tests out for performance when it's getting hit with some of these exchange feeds. But hey, that's the point - we need to be able to decouple the producers from consumers with this conflation queue.
Tomorrow is going to be putting these into some components.
This morning I was able to finish up the message cache that I started work on yesterday afternoon. It's been pretty straight forward right up until I got to the part about being thread-safe and fast at the same time. This meant lockless data structures, and that meant the compare and swap operations.
Since I'm only having one producer and many consumers, it's a thought that maybe I didn't have to worry too much about this. Well... that's a mistake. I do. But thankfully, there's only one place I need to worry about the complexities of this map - in the "setter" of the individual value.
The code I ended up with looks like this:
boost::unordered_map<uint64_t, Message *> mCache; Message *oldMsg = mCache[key]; while (!__sync_bool_compare_and_swap(&(mCache[key]), oldMsg, newMsg)) { oldMsg = mCache[key]; } // now handle the old message if (oldMsg != NULL) { delete oldMsg; oldMsg = NULL; }
where the value newMsg is the value to place in the map at the key of key.
Sure, this is greatly simplified, but the single core issue is there - we have to check to see if the value has been changed, and if it has, we need to get the new value, and then try and set our value again. The idea is that it's thread-safe, not that it's the right element in the map, but that it's the one that's put there last.
This is working great for me and while I haven't had the chance to run tests against it, it's as fast as I'm going to be able to get regardless if it's fast enough. I think it will be. I've used the boost::unordered_map which is supposed to be faster than the STL std::map which uses a read/black tree for the key space, and since my key space is a uint64_t, it's pretty easy to hash that guy - it's just the value.
I'm going to have to test this guy with the real data feeds, but I think I'm going to be OK. I feel good about it.
Today I got a tweet that Unison 2.1.1 was released, and truth be told, I knew this as I've been beta testing all the Unison 2.x releases for the great guys at Panic. It's got a few nice crashing bugs, and even a few really nagging UI issues all solved. It's just getting better and better.
Great to be a part of great software.
Well... I found out that iOS 4.1 is out for my iPhone and it includes a lot of the nice little things that we've all been hearing about for the last several months: Game Center, the improved proximity sensor, lots of bug fixes and the new camera features.
While I certainly can remember my life before the MacBook Pro and the iPhone, I can't imagine going back to that old world of desktop computers and cell phones that I turned off and only made calls on. It's a different world, and I like where it's headed.
The update isn't going to be quick, I'm betting there are thousands upon thousands of people trying to get that 500+MB file from Apple right now, but I can wait. It's enough for me to know that it's coming, and it'll all take care of itself in time.
Far be it from me to say Google shouldn't try new things. I wish they'd try not messing with Verizon on the net neutrality, or maybe just not being so overt about the complete and total lack of privacy from it's upper management, but today they released, in a very haphazard way, Google Instant, and I hate it.
OK, in my book there were a few reasons that people switched from Yahoo! to Google in the early days - one was certainly the search results, but in the beginning they weren't that much better - it still had a lot to do with the terms you asked for, and the best "search engines" were browsers that would hit a dozen search engines for you and bring it all together.
The other big driver - and certainly this was a biggie for me, was the simplicity and speed of the Google homepage. You typed into a box, hit enter, and got answers. You didn't have to wait for Yahoo!'s "portal" to load - measured in seconds, and you didn't have the distractions of the entire page. Simplicity was the rule of the day, and it was wonderful.
This morning Google has been rolling out, in fits and starts, their new offering - Google Instant. Now when you type, it immediately jumps to the answers and updates them as you type. While this may seem like a real time saver, to me it's at least a distraction, and at most, a horrible time waster.
If I need to type in a series of key words, or maybe my search criteria is more than 15 characters. The fact that it starts "searching" for me after four or five is a waste until I get to 15. I'm not done, I'm not liable to stop, and I wanted to get the search string in there. They already do "predictive searching" on the search string, which is nice to a point, because if there's a hit there, I can save myself the time, but there's no way showing me the entire search results is a time-saver. Not a chance.
I was worried that it was ON, and there was nothing I could do about it. But after a few hours, it became clear that it's something that I could turn off. I did so immediately and without a single reservation.
Guys... first, make your rollouts a little smoother - No, make that a lot smoother. There's no need for this to take an entire morning and have so many people wondering what's going on with no way of stopping it.
Next, make sure it's clear how to turn the crud off. You should have learned from Wave, and the full graphic homepage, but I guess that wasn't enough. Here... take the lesson... make it obvious how to disable the new crap. Lots of folks just want what you're good at.
I'm still shaking my head...
This morning I noticed that DrawIt 3.10.6 was out - with the ability to read/write Sketch files. Now I hadn't heard of Sketch, and I'm not sure I need to dig into it as DrawIt does all my vector drawing needs - and if it didn't, ZeusDraw does, but it's nice that they are moving in that direction. More choices and better apps are always nice to see.
This morning I noticed that I had updates from Apple - Safari 5.0.2 and iWeb 3.0.2. Very nice! I looked at the skimpy release notes with Software Update, and there are a few things for Safari - like the extensions being updated over SSL now, but for the most part, both of these are the "security and stability" update category. Someone reported the holes, and they responded by patching them.
Seems reasonable.
This morning I noticed that they had released another update to Cyberduck: 3.6.1. The 3.6 update was a few days ago, and I got it, but hadn't the time or inclination to write about it. It's now got a "nag tag" in the title bar, and while I don't begrudge anyone the ability to do what they want with their own code - especially if it's free, I do realize that I'm far happier with Transmit 4 given it's new design. It's all about file transfer, but I just enjoy the interface of Transmit 4 more.
So I got it, and then the 3.6.1 update as well, but I'm not sure I'm going to be doing a lot with them in the near-term future.
The last half of today I spent trying to figure out a really good way to incorporate a good, fast, caching scheme for these messages that are the heart of my ticker plant. The problem is that I know I'm going to be hammering the messages as fast as I can possibly take them, so a cache that locks is just right out. I wanted to make it simple as well - something parametric so it'd be easy to turn on or off and see what the difference in timing and throughput was.
The problem was, it wasn't really obvious how to do this with the given design I had.
I thought that it'd be best to put this into an existing class in the design - as low a level as possible. I was thinking maybe the component that handled simple message distribution to a list of registered listeners. It'd be nice there in that any component that "pushed" messages would be able to take advantage of this by simply "turning it on".
But there were a lot of conceptual problems. First, the messaging API used references for the messages, which is what I wanted to use, but that meant that in order to make the caching fit in without altering the API, I'd have to be making copies of the messages. That's not a good plan. Nothing good is going to come from copying a hundred thousand messages a second. That's a recipe for poor performance.
Next, if we changed the API to use pointers, and thought of the send() method as a "sink" of the message, then we'd have a nice, transparent, caching scheme, but the problem is that the messaging system relies on calling send() several times - once for each listener. This means I can't have the one method "eating" the instance as there'd be nothing left for the other listeners.
I messed around with this for a while, each time coming to the conclusion that the design I had wasn't really workable. I finally backed off and tried to think of the problem in vastly different terms.
What came to me was very simple, very clean, and in the end, far better than I'd ever have been able to do in the previous approaches.
I began to think of the cache as something of a component as opposed to a capability of the objects in the design. I started to look at the cache as something that I could put as an ivar in the few components that needed it, and make it self-contained and easy to integrate and use, and all of a sudden things started to really look up.
Now I didn't have to worry about the passing of references and how many times something is called. In anything that deals with messages, it's possible to have a cache, and that cache will "eat" messages created on the heap. It will either delete them right away (if it's inactive), or it'll save the latest, and delete the older version, so as to keep the most recent in memory and yet at the same time handle all the housekeeping for the memory management of the created messages.
Most of the components that need this caching are things that create messages. Maybe it's coming in from a serialized data stream. In that case, the created message needs to be passed to all the registered listeners, and then deleted - or cached. It's similar for different "translation components", but the model fits very well. So I started coding it up.
I didn't get finished, but it's well on it's way, and it appears to have beaten all the problems that were really dogging me with the other approaches. I know there's more to deal with - like the "fast" part, but I'll deal with that in the morning.