2013/5/6 Ludo Brands <ludo.bra...@free.fr> > In TTcpIpClientSocketThread.Execute you do a read followed by a select. > The logic is: first select then read when something is available. >
Sorry, but I don't understand well this part. :/ In the old code I not used select, and now I'm using it just to know that recv received data, but without lock the application. But if there is how to improve, feel free buddy, I noticed that you know well about sockets. :) I can add your SSH key on my Bitbucket account and you can commit directly in this code. Or, if your prefer, you can send me GIT patches. Feel free again. > The sleep(0) is not needed. Select suspends already the thread when > waiting. > Done. I removed that. > VTimeVal.tv_sec := 0; > VTimeVal.tv_usec := 100; > That is 100 microseconds which is very short. Is 500us good value for delay? > On top of that, when the timeout expires, you test if FDisconnectClient is > set and, if not set, > you do the read immediately again. The read is therefor again hanging > until something comes in. > Yes. I needed it when I made a small HTTP server and I needed to disconnect the client in each request. There are a best way to do it? :/ > Watch out for Synchronize(@DoReceive) in a recv loop. That is going to > drag down your performance considerably. > I don't understand well this part hehe... Hm... In some tests I did not see decreased performance, please could you show me an example decreasing the performance? I need to reproduce the problem, and debug the code to improve it. Thank you very much for the explanations again. On the end of it maybe we have a nice multi-threaded component for work with TCP/IP. :) -- Silvio Clécio My public projects - github.com/silvioprog
_______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal