Hacker News Reader

Comment by uriel | Hacker News Reader

Events are evil, much better use something like Plan 9 (port) libthread ( http://man.cat-v.org/plan_9/2/thread ) or Russ Cox's libtask ( http://swtch.com/libtask/ ).

Or better yet, program in Go ;)

View on HN

Most network programs spend much of their entire life waiting for IO events.

I have no argument in principle for the idea that you should restructure your whole program's control flow with transparent cooperative scheduling to attempt to get the best of both worlds of straight-line coding and efficient scheduling, except that it feels to me like you're kind of not really even writing C code anymore at that point. This might be irrational of me.

In the meantime, if you're not going to adopt an exotic thread scheduling library, I think events are the way to go. POSIX threads don't make much sense to me.

Development using coroutine libraries goes much faster and the resulting code is much more robust than that which uses events and callbacks. This is even more strongly the case in C++ where you can take advantage of traditional C++ RAII on any coroutine stack, which you couldn't do so nicely and clearly with callbacks. In the ten months since we started using them, we've had no stability problems and no strange and inscrutable bugs from within our coroutine implementation. There have been user errors from misuse of coroutines, but nothing anywhere near the order of magnitude of what you get when using callbacks.

"I have no argument in principle for the idea that you should restructure your whole program's control flow with transparent cooperative scheduling"

Maintaining any kind of long-term state for the functions which the event loop calls can be trickier than it needs to be, since they need to quickly return and can't leave anything on their stack.

Cooperative threads are implemented in terms of events.

GHC's thread system and IO manager is implemented in terms of epoll, for example.

Programs that use cooperative thread scheduling are written very different than programs that use events directly. At the end of the day, every networked program on your computer is implemented in terms of interrupt service routines, but that doesn't make Firefox a driver.

I'm just saying that events may be evil as a general purpose mechanism. But they are useful at the implementation layer of the less "evil" general purpose mechanisms.

And when I write performance-oriented C code, I use events, because great tight resource control is facilitated by that style.

Reply on news.ycombinator.com