tye++. Nail on the head time.

The client thread is calling getsockname(), meanwhile the main thread has gone back into a blocking accept(). getsockname() won't continue until the accept() completes (another connection comes in).

Likewise, attempting to set the socket non-blocking (from the thread) won't have an affect until the accept() completes. And setting the listening socket non-blocking before entering the accept() kinda negates the purpose of using threads.

A (partial at this stage), solution appears to be to change HTTP::Daemon::ClientConn (a part of HTTP::Daemon), so that it calls getsockname() on the client socket, rather than as now, on the parent.

Eg.

    $uri = $HTTP::URI_CLASS->new($uri, $self->url);
[download]

instead of:

    $uri = $HTTP::URI_CLASS->new($uri, $self->daemon->url);
[download]

which also requires making HTTP::Daemon::ClientConn a subclass of HTTP::Daemon rather than of IO::Socket::INET, in order to resolve the call to method url() which is where the call to getsockname() originates. But that seems to make more sense to me anyway?

It's still not a complete solution yet, but it does allow thing to progress past the getsockname() call which is progress. It's now completing the get_request() and returning the appropriate information to the caller, but whatever method I then call; send_file(), send_error() etc., none of the output sent by the server ever reaches the client, despite that the prints complete. Time to add some error checking on the prints in HTTP::Daemon I think.