A lookback on the past few months
It's been some time since I last blogged. My next post will be looking forward to what I'm planning to write next year, but first I should blog about what stuff I've come up with in the past couple of months.
Shared memory
I had already written POSIX::RT::SharedMem before, but even though POSIX IPC is a great idea (for being remarkably sane to use) it isn't widely implemented (Linux, Solaris and recent versions of OS X support it out of the box, FreeBSD does too but you have to enable it explicitly). Therefor I ended up writing SysV::SharedMem, which does pretty much the same thing, accessing shared memory as a string, but implemented using a different backend. It's largely derived from File::Map, unlike POSIX::RT::SharedMem that delegates most of the work to File::Map. Writing it has made my conviction that SysV IPC is an incredably crappy API even stronger, but fortunately that's largely hidden from the end-user.
Building blocks
I wrote a number of building blocks, mostly small and simple ones, though one ended up being a bit larger and more complicated than initially planned.
- Threads::Sigmask
This module enables thread specific signal masks on threaded perls, but falls back on process signal masks on non-threaded perls. - Signal::Mask
A convenient tie-based interface for signal masks - Linux::FD
eventfd, signalfd and timerfd filehandles - Linux::Epoll
A callback style scalable event multiplexer for Linux
They cover a number of different things, but there is a line through them: they are all the pieces needed to write a modern, fast and efficient event loop for Linux. There are many event-loops written in C that use these functions, but in Perl they were either unavailable(thread specific signal masks, special filehandles) or had modules that were unsatisfying to me (epoll). I'm not sure that event-loop needs to be written, but I find experimenting with it highly educational.
Misc
Other than that, an increasing amount of my time has gone to maintainance of existing modules. I'm barely past 20 and it already feel bogged by them, I can't imagine what it must be like to have 200 modules on CPAN.
You mention being unsatisfied by the current state of Epoll-based event systems. Any particular reason behind this?
Personally, I find that IO::Epoll works very well as the basis behind IO::Async::Loop::Epoll, which is the preferred IO::Async loop on Linux.
Is there perhaps something about it that I have missed?
It's not that IO::Epoll isn't a capable system. It's that its design choices make it annoying for me to use it. This however is entirely subjective. In particular:
1) It uses a polling style, where it returns file-descriptors instead of a callback-style. Epoll is a flexible, unopinionated system that allows either. Any abstraction for a high level programming language has to make a choice though.
2) It uses filedescriptors instead of filehandles. There's no reason why you should have to deal with those in perl if only because they're not very useful by themselves.
These two choices are related, though I'm sure someone else would find yet another abstraction around epoll.