Things have been going well at the OLS. I went and saw that PILS talk, but then, I still can't figure out how to get more information on the net about it. I'll ask Alan Robertson tomorrow. It doesn't seem to do much, is rather limited and doesn't seem to be that way in order to reach some anti-bloat goals or anything, just because it doesn't have much. You could probably take XPCOM and do everything it does now and almost everything on that project future directions, and even more (it doesn't support loading modules from multiple directories, for example). XPLC will soon be also on par with it.
Hugh Daniels always makes interesting talks, or at least, is an interesting speaker! :-)
The asynchronous I/O talk was excellent, but I was a bit disappointed by a few things though.
Adding a flag for having real non-blocking I/O on disk-based file descriptors was deemed pointless and that we should rather use AIO. I see things differently, as for example Squid (I think) behaves like if disk I/O did not block, like network I/O, and having it open files with a flag that would make it really non-blocking would improve performance on platforms supporting such a feature, and would be very easy to just skip on other platforms, keeping the current architecture. Some platforms would just go faster if they have the feature, which you could check with a single autoconf test.
Ben LaHaise's AIO is actually the implementation of the really good interface for event notification that Linus talked about a few years ago. Apparently that it even has the callback interface and all, but people don't want to use that callback interface and just want to call the syscalls directly, all by themselves (or closely). Fools! I talked this over with apenwarr, and while he thought that if users of this stuff would be well-mannered and followed some conventions (give any fd you might want to wait on, like ConnectionNumber in Xlib can give you), it would be okay, but my point of view is that with callbacks, you can enforce good manners. You register your interest in a file descriptor, and when an event occurs, you get notified, no matter what, even if someone else called the get_event method (or whatever it is named). Whoever is out there using Ben's AIO, use the callback interface, please!
Also, there is a hole I didn't worry much about at the time, and it is support for timers. Either you need a way to add a timer to the AIO stuff (and get notified/called back when it's ready), or a way to make a timer out of a file descriptor. Just one idea: a /dev/timer that you open, write a timeout into, and it becomes readable after the timeout expired.
I'm writing this while sitting beside the FreeS/WAN people, and I find it interesting how sometimes, some key people are just missing some part of the picture, and talking with some other people fixes their view of the world. They are obviously slightly confused (ask dcoombs!), but thankfully, some people are clued in. Unfortunately, one (Hugh Daniels, again) is shut up by his stupid government (guess which one).
I'm hacking on XPLC here at the OLS, turning the multi-binaries testing suite into a single binary, and I hit a bug. Go unit testing! I have found a problem where the single instance of the service manager dies off, and the pointer that XPLC::getServiceManager goes bad, and everything goes to hell.
I could use weak references here. The service manager currently doesn't have anything in it to enforce it being a singleton, and that is good, I like it, but now, I'll have to turn it into an enforced singleton just so that this doesn't die.
RFC: So, are weak references should go in or not?
An alternatively implementation of the X stream protocol
Well, thanks again to raph for the link to XCB. This is pretty similar to XPLC, in the sense that in order to achieve goals of lightness and performance, they sacrified some other features that might be some other people's sacred cows, but that (if only those people would just open their eyes) aren't really needed.