Hi Glyph and Folks:
AM>I would be actually quite curious to know the rationale of choosing
AM>select() over epoll() these days. epoll() scales like O(1) with the
AM>number of file descriptors, it is very performant, stable, and has no
AM>limitation on the overall number of fds on linux (except for your /proc
AM>and ulimit -n settings). I'd use epoll reactor, unless you have some AM>very
specialized requirement.
G>Short answer: because select() is always available.
Thanks. I do most development in Linux now.
The main thing I wanted to avoid was altering file descriptor limits and
bundling a new AMI and still not having the ability to test above a certain
descriptor limit.
After the semester is over, I want to conduct some new tests with Stackless
Python and Twisted. I am also playing with new designs. I am interested in
comparing Stackless/Twisted solutions to pure Twisted solutions (just to gauge
of inefficiencies).
I am particularly interested in how channel preferences (a Stackless scheduling
mechanism) affect certain performance metrics depending on the number of (and I
guess duration) of connections. I will probably start looking at Reactor code
again. This is why in the donate time thread, I was willing to volunteer time
there (if I can actually be of help)
Cheers,
Andrew
_______________________________________________
Twisted-Python mailing list
[email protected]
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
