uuidd.py. Neat implementation of an ID server from Mike Malone—it serves up incrementing integers over a socket (using Python’s asyncore for fast IO) and records state to a file only after every 10,000 IDs served, so most of the time it’s not reading or writing to disk at all. If the server crashes it doesn’t matter because it can start up again at an integer it’s sure hasn’t been used before.
Sign in with 
OpenID
Maybe not immediately obvious, but because of the locking semantics, it's safe to run multiple daemons using the same uuid.txt on different ports.
They jump over each other at the range boundaries.
Jeremy Dunck - 26th May 2009 02:36 - #
Very neat, I hadn't spotted that. Presumably that's so you can run one instance per core and hence work around the GIL.
Note that the name is not accurate. Unless the UUID in uuidd.py stands for something else besides Universally Unique Identifier.
Serving incrementing integers is in no way universally unique.
A better name might have been autoincd.py since it behaves much more like an auto-increment field from a database.
Joseph Scott - 26th May 2009 17:43 - #
Ha, Simon you're seriously on top of things! This is just something I've been toying with the last couple days. Joseph, yea it's not really a UUID... unless by "Universally" you mean "within the context of your application, where every object uses this method to get an ID." ;)
With a bit more code I think you could make this scale more or less horizontally, too. If you get beyond the point where one server is fast enough (which is _really_ big), you could have multiple tiers of servers and have the higher level's request a range of IDs from the authoritative backend server. So your clients would talk to the front end servers, and they would talk to a single backend. For redundancy I've also been thinking about implementing a simple master-master system with two-phase commit for the daemon.
Anyways, glad you like it ;).
Mike Malone - 26th May 2009 19:11 - #