"Bill Stoddard" <[EMAIL PROTECTED]> writes: > > Have either of you benchmarked with apr_poll() or are you assuming that > > the problem exists? > > > > Ryan > > > > > > Sorry didn't answer you here... There definitely are extra instructions and > function calls involved with using apr_poll() in this case. I don't know the > exact number but I could find out. The affects of a few dozen extra > instructions would be insignificant in overall server performance, but you > can say that about any place in the server. Adding function call overhead > adds up. In this case, is easy to just avoid the extra calls altogether with > no significant loss in code readability.
Using apr_poll() is more complex than using poll() in this situation. We'll have to be careful not to leak storage (i.e., create/destroy a subpool or attach the apr_pollfd_t to the apr_socket_t the first time we need to wait_for_io_or_timeout. And since this deals with more than just sockets we'll have to play with the interface to wait_for_io_or_timeout. So we munge a lot of code so that we only call poll() from one place and we're left with extra complexity and extra pathlength. An implementation using apr_poll() which is more complex and less speedy by inspection than using poll() directly is going to be vetoed. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
