Head on with select

And we attack select with epoll. Or so we thought.

Having written basic sever programs with select and epoll, we could figure out there was some sort of a correspondence between the two. For instance the select( ) call was to be replace by epoll_wait( ) and so on. Select definitely did not have an equivalent for all the other calls and the variables required for epoll mechanism but we could generalize.

So when the task of converting the approach of the web server to an epoll based one, we naturally assumed that all we had to do was a mapping. We did not expect it to be simple though, but we made a mistake, a huge one - of ASSUMING. One of our professors always told us what-ever we do, we definitely should not assume.

And this led to few difficulties.


We has initially thought we could use the information of the vague sort of mapping that existed between the two server programs written using select and epoll approaches.
But that was absolutely not true!
As all things are relative, so are programs!
The very essence of boa being the select approach to web server architecture, it had its entire code centered around the setting and "unsetting" of various fds.

FD FD everywhere, not a FD to set, FD FD everywhere, not a FD to clear!

As we know, with epoll we do not fiddle with file descriptors at all! Events, just pure events! True, we cannot call them pure, since epoll is not completely based on the pure event based structure. We shall not digress here about epoll though. Will write about it some other day perhaps.

With no fds in hand, and just a bunch of events, the entire idea of some sort of a mapping went for a toss!

With select, the entire game involves playing with the fd sets. In epoll, we do not have such a direct handle of the fds. On top of that, a single event set in place of two different versions of write fd-set and read fd-set led to further considerations to be looked into, while trying to map the same.