in reply to Re: Re: RE(4): MP3 server with IO::Socket
in thread MP3 server with IO::Socket

Remember how I said I assumed the forking code was fine? Well, I grabbed your latest code posting, and to my surprise, it wouldn't run! After some more debugging (looks like I'm reading more code than I'm writing lately) I think I've found a contention issue (not really sure)...anywho: 
else
{
 #i'm the parent!
 warn "(Parent) I'm the parent\n";
 #who connected?
 warn "(Parent) Connecton recieved ... ",$connection>peerhost,"\n";

 #close the connection, the parent has already passed
 #   it off to a child.
 warn "(Parent) Closing connection\n";
 sleep 3;
 $connection->close();
}

[download]
Those extra warn statements lead me to believe that the parent was closing the $connection before the child got to call play_songs hence the sleep call. I chose "3" randomly, but it works fine now, and the sleep doesn't affect any of the logic or flow. Brainiac

Replies are listed 'Best First'.
Re: Re: Re: Re: RE(4): MP3 server with IO::Socket
by perlmonkey (Hermit) on Mar 10, 2001 at 05:27 UTC
    Thanks for the feedback. You must be experiencing some Windows wackyness. Here is some of the logic behind the forking. The parent is not *really* closing the client connection as far as the client is concerned. In a normal Unix operation, the fork will create duplicate file descriptors for all open files (includeing sockets). The child has access to the listen socket and the client socket, but also the parent has access to both sockets. The parent and child have independant file descriptors. So if the parent closes its file descriptor, the child still has it open and the client will still remain connected. Both parent and child have to disconnect from the client before the socket is closed. After the fork the parent and child both have valid sockets connecting to the client. Since the parent doesnt not need its end of the client socket it closes it's piece. But the child's copy of the connection is still open since it has not closed its own copy. Similarly the child does not need the listen socket anymore so it closes it's copy of the listen socket, this does not close the parent's listen socket ... so the server keeps listening. Only when the child closes the client socket does the socket actually close.

    Now that was Unix-land. The rumors I have heard are that Windows-land implemented fork using threads, instead of spawning new processes ... so there could be problems with file handles not being duped with the copies being sent to the child. The only thing that I can think of that a sleep 3 would help would be in the unlikely event that in the windows fork implementation the new thread start running right away leaving the 'parent' thread to continue on it's merry way, while the 'child' thread attempts to dup the parents open filehandles in order to mimic the Unix fork. If the 'child' thread does not have time to dup the file handles before the 'parent' thread closes them then you would get the behavior that you describe. I would consider that to be a bug in the windows implementation of Perl then. Perhaps it would fix things if you upgraded your perl to the latest from ActiveState? Just a thought. Other than that I cant think of a thing that would cause what you describe.

    If there is anyone wise in the way of windows-perl, I am interested to hear if there is a firm answer to this problem.
    -perlmonkey
[reply]
[d/l]
[select]

In Section Tutorials