use epoll/kqueue/signal-driven IO

There are several problems with that advice:

• They're not available from Perl.
• They'e not POSIX.

  I agree, POSIX is increasingly irrelevant as it isn't a useful representation of *nix any more. (Or for the last two decades for that matter.)

• epoll doesn't work with timers, signals, semaphores, processes, network devices. Not even disk files.

  Yes, there are the calls signalfd(), eventfd(), and timerfd_create(); but they don't help much.

• epoll maybe O(1) for event notifications, but it remains O(n) for modifications to the interest set.

  Fast changing, dynamic descriptor sets require many and frequent calls into the kernel for epoll_ctl(), which gets expensive.

• kqueue addresses most of that, but retains one major flaw in modern systems: Per process interest sets.

  Basically, it hasn't caught up with the advent of the multi-core architectures that are now ubiquitous; which means you can't easily split your loads across those multiple cores by using multiple thread running separate event loops.

  Yes, you can use multiple processes; but that creates the problem of coordination and data sharing between those processes.

Hey, BrowersUK, some of your objections are just bizarre.

They're not available from Perl.

What

"epoll doesn't work with timers, signals... yes, there are the calls signalfd(), and timerfd_create()... they don't help much"

??? BTW, none of the IO multiplexers (to my knowledge) do anything useful with hard disk files.

"epoll maybe O(1) for event notifications, but it remains O(n) for modifications to the interest set"

you found that a problem in practice? Tell me more...

fast changing, dynamic descriptor sets require many and calls into the kernel for epoll_ctl(), which gets expensive.

"fast" compared to what? compared to the speed of CPUs, or compared to the speed of IO that you're presumably doing on these descriptors in between opening and closing them?

kqueue addresses most of that, but retains one major flaw in modern systems: Per process interest sets.

Now, I haven't actually used kqueue (since that's a BSD thing). But you said "retains", and that's wrong: you can create as many epoll instances (sets) as you like, and monitor them separately (using threads, if you like). Actually, kqueue man page says:

The kqueue() system call fails if:
     [ENOMEM]    The kernel failed to allocate enough memory for the k
+ernel queue.
     [EMFILE]    The per-process descriptor table is full.
     [ENFILE]    The system file table is full.
[download]

Where does it say "you already have one queue in this process and can't get more"?

Basically, it hasn't caught up with the advent of the multi-core architectures that are now ubiquitous; which means you can't easily split your loads across those multiple cores by using multiple thread running separate event loops.

Sure you can, if that's what you want to do, for some reason...

Really, your points look pretty strange to me, except maybe for adding more than one fd at a time to epoll instance. Well, that looks like it wouldn't be difficult to implement, but it wasn't, so I guess other people didn't feel the need for it either.

you found that a problem in practice?

No. I have no direct personal experience of any of it. I was just countering the patronising tone of the post to which I replied.

I did however learn a little of the limitations of *nix event loop processing in relation to a piece of work I did almost 4 years ago. (There's even a question I asked here that came out of it.)

Essentially, that piece of work involved developing a high-performance, high-availability, low-latency distributed caching mechanism. Kind of like memcache on steroids (and actually a replacement for it for a very particular purpose).

My involvement was purely on the hashing side of the problem with other people taking care of the network stuff. But for my own development & testing purposes, I wrote a (simple; C) multi-threaded event-loop server because the real thing was being written for Linux, and I don't run Linux.

In one of my communications with the server developers, I happened to mention the kind of response rates I was getting and they basically accused me of lying. They simply didn't believe the numbers I'd mentioned; as their pselect server was achieving nothing like the same.

Some of it was down to the fact that I wasn't actually responding with a full response to the clients; just closing the connections. Some was due to the fact that the "clients" were another multi-threaded, multiplexing program pretending to be lots of clients, and running in the same box, thus excluding all network latencies and much of the stack latencies.

But the primary problem was the O(n) inefficiency of pselect. And so I got to watch (via email) as they went through the various options available and see the objections raised by various parties. What I posted was basically a summary of them; except I added the 'not available from perl' (the OP's question was a Perl application).

The initial trial was done using kqueue and processes under RedHat. For production it was replaced by multi-threaded, multiplexing server using Alertable I/O under Winserver 2008.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)

In the absence of evidence, opinion is indistinguishable from prejudice.