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.

2 Comments

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?

Leave a comment

About Leon Timmermans

user-pic