libevent and Solaris event ports

For those who dwell in subterranean shelters, event ports (or the "event completion framework," if you want) are the slick new way to deal with events from various sources, including file descriptors, asynchronous i/o, other user processes, etc. Adam Leventhal even thinks they're the 20th best thing about Solaris 10. Okay, that's not huge, but competing with zfs, dtrace, and openness, that ain't half bad.

Though the interface is, of course, well-defined, the framework is still evolving. People are talking about adding signals and filesystem events to the event completion framework, though there's definitely some debate about how to go about doing that.

Now I hear you asking me: "Okay, that sounds pretty cool, but why would I port my sw33t @pp to Solaris just for event ports? Or port my existing poll(2) implementation on Solaris to use these newfangled dohickeys?"

Well if amazing scalability isn't an important enough reason, then I don't know what is. (One of the great properties of event ports is they scale with the number of actual events, not the number of descriptors you're listening to.)

But reworking your code could come with added benefits.

Enter libevent. Libevent is a portable library for dealing with file descriptor events. "But wait," you ask, "I thought that's what event ports are for!" Well, libevent provides a portable API for doing this. But the implementation varies from system to system. On BSD, it might use the kqueue facility, while on GNU/Linux it might choose epoll. This way, you can write your program on one platform, move to another, recompile, and all your file descriptor polling code works fine (albeit probably with a different implementation, which may affect performance substantially (possibly for the better, since the library chooses the best one for your platform)).

Now libevent could use event ports as a backend on Solaris 10. It's a project I've been working on for the last week or so. With that, you get the portability of libevent plus (some of[1]) the scalability of event ports. Sweet.

Oh, and if you're wondering more about event ports, check out the engine room, which includes an example and more technical information.

[1]: the event port libevent backend isn't quite as scalable as event ports alone, because a bit of per-descriptor bookkeeping has to be maintained. D'oh.

Comments:

Dave, Make sure you mention this on the memcached list <http://www.danga.com/memcached>. There are lot of high-profile users there who would like to have dtrace and libevent with event ports

Posted by Yusuf Goolamabbas on June 14, 2006 at 06:23 PM PDT #

Post a Comment:
Comments are closed for this entry.
About

On Fishworks, Sun, and software engineering

Search

Archives
« April 2015
SunMonTueWedThuFriSat
   
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
  
       
Today