Hmm. Have you managed to track down what code is executing when that silent abnormal termination occurs?

Yep, with some extra logging..

First, I added this in main to prevent the abend:

$SIG{PIPE} = sub { $log->warning("Caught SIGPIPE:  $!"); $running = 1;
+ };
[download]

Then added this in the handler thread:

        $log->warning("In thread: Attempting to shutdown handle associ
+ated with fileno: $fno");
        shutdown ($socket, 2) or $log->warning ("In thread: Shutdown e
+rror: $!");
        $log->warning("In thread: Attempting to close handle associate
+d with fileno: $fno");
        close $socket or $log->warning ("In thread: close error: $!");
        $log->warning("In thread: Enqueing in Qclean fileno: $fno");
        $Qclean->enqueue( $fno );
[download]

I simulate a connection from client:

$ perl -e 'printf "<request>getmyip</request>%c",0' | ./nc myhost.com 
+9999
[download]

The connection is immediately closed as desired, but I get nothing back from the server for my request, when --according to the code in the thread-- I should be getting this back:

<data><ip>x.x.x.x</ip></data>
[download]

The output in the log:

August 29 09:12:44 xmlsockd-advanced[32652]: (1) : XML IP request from
+: x.x.x.x
August 29 09:12:44 xmlsockdx[32652]: In thread: Attempting to shutdown
+ handle associated with fileno: 5
August 29 09:12:44 xmlsockdx[32652]: In thread: Attempting to close ha
+ndle associated with fileno: 5
August 29 09:12:44 xmlsockdx[32652]: Caught SIGPIPE:  Broken pipe
August 29 09:12:44 xmlsockdx[32652]: In thread: close error: Broken pi
+pe
[download]

Caused by the close() call after shutdown() in the handler thread (the code you previously suggested), not the close() in Main!

I go ahead and remove the close() call in the handler thread keeping only the shutdown() call, so it will look like this:

$log->warning("In thread: Attempting to shutdown handle associated wit
+h fileno: $fno");
shutdown ($socket, 2) or $log->warning ("In thread: shutdown error: $!
+");
$log->warning("In thread: Enqueing in Qclean fileno: $fno");
$Qclean->enqueue( $fno );
[download]

And in the main accept() loop I also remove the close() call, so it will look like this:

    while ( $Qclean->pending )
    {
        my $fileno = $Qclean->dequeue();
        delete $sockets{ $fileno };
    }
[download]

Again, I simulate another connection from client via shell:

$ perl -e 'printf "<policy-file-request/>%c",0' | ./nc myhost.com 9999
[download]

I should've got this response:

<?xml version="1.0"?><cross-domain-policy><allow-access-from domain="*
+" to-ports="9999" /></cross-domain-policy>
[download]

But again, the connection is immediately closed on the client side before they even receive a response to their request as coded for in the handler thread..
This is very bad!

Now the log shows:

August 29 09:26:31 xmlsockd[7815]: (1) : XML IP request from: x.x.x.x
August 29 09:26:31 xmlsockd[7815]: In thread: Attempting to shutdown h
+andle associated with fileno: 5
August 29 09:26:31 xmlsockd[7815]: In thread: Enqueing in Qclean filen
+o: 5
August 29 09:26:31 xmlsockd[7815]: Caught SIGPIPE:  Broken pipe
[download]

Probably as I said previously, having the shutdown on the dup handle in the thread causes SIGPIPE to be thrown because the main handle is still open in the main accept() thread. And for whatever reason (which I am unaware of), whatever the handler thread wrote back on the socket prior to the shutdown is lost and is not sent to the client. Hmmm???

However, if I _remove_ the shutdown() call from the handler thread (keeping only the "close $socket" line), the client's request gets back the proper response, only it doesn't get immediately closed (until another connection comes in as we previously established)

In my tests (under win32), if I dont use shutdown in the hendler thread, the client connection stays open until the main thread gets around to closing its copy of the socket.

Did you actually get a response back for your request when you have shutdown() in the handler thread?
Are you ignoring SIGPIPE?

Maybe Win32 doesn't blow up with SIGPIPE when a handle is closed somewhere in the code while it's still open elsewhere?
Still, it certainly does on *nix according to my testing...