M2Crypto: select() behaves weird on SSL sockets

[Kragen Sitaker]

"Steve Holden" <sholden at holdenweb.com> writes:
> "Irmen de Jong" <irmen at NOSPAMREMOVETHISxs4all.nl> wrote in message
> news:3D1B92A2.7030605 at NOSPAMREMOVETHISxs4all.nl...
> > Kragen Sitaker wrote:
> > > What I guess you're not aware of is that asyncore supports the middle
> > > ground (middle colors?) as well as the event-loop-driven end of the
> > > spectrum.  For example, Zope has an asyncore thread that handles I/O,
> > > but actually processes requests and produces results in some child
> > > threads.
> >
> > You're probably right. I don't know a lot about the workings of asyncore.

It's pretty simple if you already understand select().  It might be
simple even if you don't.

> I understand that Zope used the asyncore code as a basis for development
> rather than adopting it outright, but I haven't actually checked the source
> to ensure this is so.

Zope 2.4.2 on my machine uses the asyncore that ships with Python
rather than using one of its own.

> > Doing stuff the Zope way, the worker threads must have some way to
> > get to the input and output streams that are handled in asyncore, right?

Yes.

> Well, it's a relatively simple matter: when an asyncore channel's
> handle-connect() method is called, one fo the arguments is the socket that
> was created by the connection. handle_connect() simply uses this socket to
> create another channel, which is added to the map used by the asynchronous
> select() loop.
> 
> This new channel then starts to fire handle_read() method calls, which you
> service by doing something with the data. If the something you do includes
> putting data in an output buffer then handle_write() events also start to
> occur.

I think Irmen was asking, if the data handle_write is going to write
is generated in another thread, how does it get written to the output
buffer?  Zope contains FIFOs, which look non-thread-safe to me but
seem to work, that carry the data between threads.