As of d62ad96, when the connection can't receive more data from the
client, it tells the actor to stop the connection and calls
disable_recv(). The actor operates in it's own thread and when it stops
the connection, disable_recv is being called again from a different
thread. Since the actor is told to stop the connection before
disable_recv is called, the two calls to disable_recv may happen
simultaneously.
This causes a race condition issue where both threads can reach past the
check that recv_id is not None before either of them set it to None. If
one of them set it to None before the other one tries to use it, an
error is raised.
This commit calls disable_recv before telling the actor to stop the
connection. Since disable_recv is a blocking call, this ensures that
recv_id is being set to None before the actor thread begins to stop the
connection.
Fixes#781
This makes a connection tell the actor to stop the connection, instead
of stopping it itself. This is preferable, because other messages sent
to the actor that is not processed yet, may now send data to the client.
E.g. it makes this work:
$ echo status | nc localhost 6600
IOError messages are bytestrings, often in the language of the system, so they
may include non-ASCII characters. Thus, we must decode them using the locale's
preferred encoding to get Unicode objects we safely can pass on for logging
the IOError.
This implies that the Server class is in charge of just listening and starting
up new clients. Clients are expected to run in the event loop thread, so they
only deal with minimal IO/network concerns. Each client has a protocol actor
that does the actual work.
