in reply to Sharing sockets between the main script and thread
#close filehandle before detached thread dies out close( $lclient); #remove multi-echo-clients from echo list @clients = grep {$_ !~ $lfileno} @clients;
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^2: Sharing sockets between the main script and thread
by markseger (Beadle) on Nov 28, 2008 at 21:57 UTC | |
That said, here's the server code. The way it works is it receives a connection from one or more clients and then starts printing the value of $count to them. There's also a sleep statement at the bottom of the main loop which you can uncomment to speed up the amount of messages sent to the client. You can start/stop one or more clients while this is running and other than that problem with the print statement it seems very solid to me. You can also stop/start the server and the clients will reconnect when the socket becomes available. Also note I have a bunch of logging messages that helped me coordinate problems between the client and the server. Easy enough to turn off. SO here's the main server code with LOTS of error handling... And here's the client I test it with. To run it the first argument is the address for the server - I've been doing all my testing with both client/server on the same system. If you specify a second argument, the client will read a response, sleep for a second and read another, looping until you ^C and it will exit cleanly so you can restart it. As I said you can run multiple instances, starting/stopping them and they do the right thing. Finally, if you give it a 3rd argument it will skip the sleep 1 and connect/disconnect as fast as possible. If anyone has any clue why it only works correctly with that "print top" statement I've love to hear an answer. In the case of my collectl script I don't have this problem, but there is also a lot of other activity going on the main processing loop so perhaps that's why. I also suspect my scripts could be somewhat more compresses but I guess I've always been in the habit of being more verbose so both myself and others could better understand what I'm doing... -mark | [reply] [d/l] [select] |
by BrowserUk (Patriarch) on Nov 29, 2008 at 13:06 UTC | |
If anyone has any clue why it only works correctly with that "print top" statement Quite frankly, if your code does indeed work correctly with that "print top" statement, then I'd just leave that statement there. Then, I'd contact the Magic Circle and show it to them because they'd probably pay you a big lump of cash once they work out how it "works", because they'll be able to use for as the basis of some damn good illusions. If you add use strict: to the top of your program and fix all these errors:
You might get close to understanding some of your problems. The entire logic of your code is dependant upon this hash %sockOpened. You use it to direct the flow of your program all over the place:
But you never declare that variable, and you never write to it, so what is it that you are testing? I also suspect my scripts could be somewhat more compresses but I guess I've always been in the habit of being more verbose so both myself and others could better understand what I'm doing... Sorry, but it doesn't seem to be working for you. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] [d/l] [select] |
by markseger (Beadle) on Nov 30, 2008 at 12:38 UTC | |
As for $sockOpened not being used, it IS being used. If you look at then 'open' statement you'll see that array contains the file descriptors of each opened socket. In any event I finally found the problem! The bottom line is that although I do my locking at the top of the main while loop, there is virtually no time for the CPU to yield any time to the thread, which itself is hanging on a lock(). The 'print' statement causes it to yield and for that matter replacing it with anything that will yield the cpu will do so. I tried threads->yield which also worked as well as sleeping for 0.01 with select. In any event, if you want to take a look at one that does work AND includes strict: There actually is a bonus question to all this which I suspect is buried in the guts of TCP. If you run the server with the 'select' at the top of the loop commented out and then run the client scrip from the base note with the format 'client address 1', it will connect the server, read a record, close the connection and try to reestablish the connection. Everything will hang. If you immediately do a netstat -a, for some unknown reason the server immediately wakes up and I have no idea why... In any event if you DO leave in the select it runs just fine. -mark | [reply] [d/l] |
by BrowserUk (Patriarch) on Nov 30, 2008 at 15:39 UTC | |
by markseger (Beadle) on Nov 30, 2008 at 16:01 UTC | |
| |