M2Crypto: select() behaves weird on SSL sockets

[Steve Holden]

"Irmen de Jong" <irmen at NOSPAMREMOVETHISxs4all.nl> wrote ...
> Steve Holden wrote:
>
> > asyncore/asynchat really repay the effort of study, so I would advise
you to
> > take a fresh look when you get time.
>
> I will. Am I correct to conclude that the benefits of using asyncore as a
> basis for Pyro are:
> 1. uses a well-tested stable I/O module (though the current implementation
>     in Pyro isn't bad at all)

Certainly the code is pretty sound, being (among other things) the basis of
the server used in Zope.

> 2. able to process multiple requests without using threads, because
>     the I/O is multiplexed

Yes, although there may be other benefits to multi-threading. For example, I
wrote a web framework using a relational database to grab content. In its
naiive state (i.e. as implemented) each transaction must terminate before
the next one can begin. If I had used a thread-per-request implementation
(which wouldn't have been that hard, IIRC) then the slack time during
database access would have been available to the other requests, which I
anticipate would have improved throughput in heavily-loaded environments.

> 3. able to handle very many concurrent connections (no thread overhead
>     per connection -- but is a thread really that heavy?)
>
The effbot said: """lot's of information and links here:

    http://www.kegel.com/c10k.html"""

I can't say better.
>
> > To assist you, I plan to add documentation for asynchat for 2.3.
>
> That's nice because I was looking for that one just yet :)
> But glancing at the code of asynchat makes me think that this
> one isn't suited for Pyro because Pyro is no line-based command-response
> protocol.
>
I don't know the details of Pyro, but I imagine the interactions could be
similar to web interactions: sometimes you want to recognise a particular
string in the datat stream (like the empty line that terminates the headers)
and sometimes you want to read a fixed number of characters (such as when
guided by a "Content-Length:" header). Naturally, that would be your call.

> > when-sourceforge-stops-playing-silly-buggers-ly y'rs  - steve
> What's wrong with SF?
>
It was just running like a dog the day I wrote that. SF can get a bit slow
at busy times.

> Cya

why-should-i-cover-my-ass-ly y'rs  - steve
-----------------------------------------------------------------------
Steve Holden                                 http://www.holdenweb.com/
Python Web Programming                http://pydish.holdenweb.com/pwp/
-----------------------------------------------------------------------