Hacker News Reader

Comment by cjensen | Hacker News Reader

The phrase "fundamentally broken" is overblown when referring to a syscall that works fine for most applications. "Doesn't scale" may not sound as glamorous in the title, but it's a lot more accurate.

Back in the old single-threading Unix days, select() was a good choice because it allows you to write a program handling async inputs in an easy style.

View on HN

It's not just works, it's actually the only one that works properly for most things and is the most portable across OSes.

I was kinda embarrassed about making a new program with select() a few years ago. I'd rather have written something with a epoll or kpoll or something like that, but the documentation was pretty bad and I never got them to work. Anyway it doesn't need to scale, it only ever has three servers talking to it. Works great, whether I like the style or not.

Hence libevent (&c). Coding direct to select is a little like reading directly from /dev/bpf0.

That's probably fair, but beej's guide corrupted me. It's just too user-friendly. I'll look around again for the next project though.

select() has its uses and servicing a small handful of sockets is one of them. Nothing to be embarassed about.

In my defense, I never said "don't use select(2)". The point I want to get through: due to the semantics, it's impossible to create a fast kernel side implementation of select().

I liked your article and it got me thinking about your point a lot. I'm just whining about the title since I think it could be improved. Would like to also see some text that mentioned that the inefficiencies add up so that it mostly matters when scaling to large numbers.

Thanks for writing it -- it's a good contribution!

And select() is still a perfectly good option for situations where the number of FDs involved is constant, or at least stays small. For instance: for networking in an X11 application, using a select()-based event loop is much simpler than creating a thread for each socket.

You should never, ever, create one thread per socket. The choice is between select, polled IO, or events. Sadly, UNIX doesn't have a good unified asynchronous IO model, like OVERLAPPED and IOCP on NT.

> You should never, ever, create one thread per socket

Really? that's how MySQL works.

And even when the number of FDs grow large, epoll() (which is like select()) in Linux is often preferable spawning threads.

i'll just leave this here is case someone walks by and thinks it looks interesting

http://homes.cs.washington.edu/~tom/pubs/sched_act.pdf

Reply on news.ycombinator.com