3 ms·
In all sincerity, I'd like to understand how and why you would use libevent instead of the approach outlined by Beej, Is there any link or other reference you
by phugoid 17y ago
In all sincerity, I'd like to understand how and why you would use libevent instead of the approach outlined by Beej,
Is there any link or other reference you could recommend for further study? The documentation on libevent's home page is big on "how", but not on "why".
- tptacek 17y agoBeej's guide is really about writing synchronous network code. You connect a socket. Your program waits for the connect to complete. You write something to the socket. What, the write might only complete 10 of your 20 bytes? Wrap the write in a loop that keeps feeding more bytes to the system call! Ok, the request is completely sent? Great! Now write a loop that sits there waiting for all the data that we need to come back on the socket. Back and forth, back and forth, in lock-step. Efficient network code just isn't written like this. It's scheduled, the same way processes are in the kernel. Even in threaded code, nothing sits there waiting on a socket. Beej touches on this a little with his description of select(). But select isn't a utility function in socket programming. It's the kernel. And getting that loop completely right isn't trivial (timers alone can offer you 4-5 mainstream data structures to choose from). Moreover, select isn't the end-all kernel interface to scheduling I/O; if you're writing a server, it's probably much faster to use a more modern interface. Libevent both hides the complexity of the event loop from you, and also abstracts it so you can drop in kqueue or epoll or whatever without being tied to a single old system call interface. None of this is a knock against Beej's guide. I loved this thing, 15 years ago. =)
- phugoid 17y agoThanks for the crash course.