> Why must I use threads? You must use threads in blocking tcp/ip else you will hang your application everytime the network traffic slows or the application you connect to (server?) does not immediately respond. Try changing your calls to blocking and see what happens.
> Following works perfectly for me for many years: > > ioctl(Sock,FIONBIO,@tmp); // nonblocking > > All but one applications are single thread. Yes. You are using the 'work around'. Traditional UNIX sockets block. Microsoft (and others) realised this would not work with a co-operative multitasking operating system (e.g. Windows 3.1, MacOS 9 and prior) and so the idea of non-blocking sockets was concieved. Indeed M$'s first Winsock implementations used purely Non-blocking sockets. The tcp/ip developer has two avenues to wander down. Use threads and blocking api. It's fast and responsive and we only have to worry about sharing data between threads, or use non-blocking code and then have to work around the fact that tcp/ip can be slow and we will not get all my data in one big chunk. Using Non blocking sockets means that your code becomes more complex and convoluted because you may well have to go through the event look many hundreds of times before your download or upload has completed. Using multiple threads, you simple hand the data over to the thread when uploading and either carry on. Downloading you simply send a message to the main thread when the data is ready. It's also easy to simulate non-blocking sockets with blocking code using threads. This gives you a clear seperation between your tcp/ip mechanism and your application code. This is the route we usually take here. Swings and roundabouts, I know ;-) Matt _______________________________________________ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
