On Wed, 25 Nov 2015 20:33:41 GMT, Usman Malik wrote:
Please ignore the issue has the conn object which is no longer available because I had a this.conn.close(); call earlier.
Thanks
Just for completeness, I'd recommend the following structure:
shared static this()
{
listenTCP(25, (conn) {
auto client = new Client(db);
client.handleConnection(conn);
});
}
class Client {
TCPConnection conn;
void close()
{
conn.close(); // will cause the loop in handleClient to exit
// destroy(this) wouldn't free any additional resources
// at this point - conn and task already have their resources
// freed. You could do "delete this;" but it's usually a
// better idea to let the GC take care of it, or use
// RefCounted!Client instead
}
void handleConnection()
{
while (!conn.empty) { // returns false when the connection gets closed
auto ln = cast(string).conn.readLine();
processLine(ln);
}
}
}
This avoids a long-running constructor, and drops the task completely. When listenTCP() calls the callback delegate, that already happens within a newly started task, so starting another one in this case just produces overhead. Instead of .connected, you should always use either .empty or .waitForData() when followed by a read operation. .connected is for checking if the connection is ready for writing. This distinction is important, because the TCP connection can be in a half-closed state where only one of the two is still possible.