ME> Use threads and blocking api.
I have (almost) nothing against threads, but they definitely have
disadvantages to, especially when used in a huge project:
1. synchronization - need to use critical sections / locks
2. they are very hard to debug and time dependant bugs can be
introduced.
3. many libraries (general/graphic/sound/db/etc.) are NOT thread safe
That's why I prefer non-blocking single thread solutions.
vtech
ME> It's fast and responsive and we only have to worry about
ME> sharing data between threads, or use non-blocking code and then have to work
ME> around the fact that tcp/ip can be slow and we will not get all my data in
ME> one big chunk. Using Non blocking sockets means that your code becomes more
ME> complex and convoluted because you may well have to go through the event
ME> look many hundreds of times before your download or upload has completed.
ME> Using multiple threads, you simple hand the data over to the thread when
ME> uploading and either carry on. Downloading you simply send a message to the
ME> main thread when the data is ready. It's also easy to simulate non-blocking
ME> sockets with blocking code using threads. This gives you a clear seperation
ME> between your tcp/ip mechanism and your application code. This is the route
ME> we usually take here.
ME> Swings and roundabouts, I know ;-)
ME> Matt
ME> _______________________________________________
ME> fpc-pascal maillist - [EMAIL PROTECTED]
ME> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
--
Best regards,
vtech-fpc mailto:[EMAIL PROTECTED]
_______________________________________________
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
