5 ms·

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

by cjensen 10y ago

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.

zzzcpan 10y ago
It's not just works, it's actually the only one that works properly for most things and is the most portable across OSes.
- sp332 10y ago
  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.
  - tptacek 10y ago
    Hence libevent (&c). Coding direct to select is a little like reading directly from /dev/bpf0.
    - sp332 10y ago
      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.
  - eps 10y ago
    select() has its uses and servicing a small handful of sockets is one of them. Nothing to be embarassed about.
duskwuff 10y ago
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.
- ktRolster 10y ago
  And even when the number of FDs grow large, epoll() (which is like select()) in Linux is often preferable spawning threads.
- jwatte 10y ago
  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.
  - snnn 10y ago
    > You should never, ever, create one thread per socket Really? that's how MySQL works.
majke 10y ago
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().
- cjensen 10y ago
  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!
convolvatron 10y ago
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 http://homes.cs.washington.edu/~tom/pubs/sched_act.pdf

by cjensen 10y ago

zzzcpan 10y ago

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

sp332 10y ago
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.
- tptacek 10y ago
  Hence libevent (&c). Coding direct to select is a little like reading directly from /dev/bpf0.
  - sp332 10y ago
    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.
- eps 10y ago
  select() has its uses and servicing a small handful of sockets is one of them. Nothing to be embarassed about.

duskwuff 10y ago

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.

ktRolster 10y ago
And even when the number of FDs grow large, epoll() (which is like select()) in Linux is often preferable spawning threads.
jwatte 10y ago
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.
- snnn 10y ago
  > You should never, ever, create one thread per socket Really? that's how MySQL works.

majke 10y ago

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().

cjensen 10y ago
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!

convolvatron 10y ago

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 http://homes.cs.washington.edu/~tom/pubs/sched_act.pdf