I've to rebuild some piece of my application because it fails after 
relatively short amount of time and I don't find the fault.

It uses TWSockets on two occasions: one for up to ten parallel 
communications via UDP and one time for sending the results of these 
communications and for receiving new requests via TCP to another PC.

Now it's based on threads, each of these parallel lines has a thread 
which also does the timeout checking. I want to change that to simple 
objects which use a timer each for that to simplify it. Another thread 
currently watches the global receive buffer where each of these lines 
stores its received data in (after validating it). If received data is 
present it gets sent via TCP.

The ned idea is that these timer based communication lines still write 
to a shared global buffer and there is still a thread reading it out 
which gets notified via PostMessage that there is something to do, to 
keep the thread of CPU-hogging. The problem now is, how to effectively 
lock the list so that always only one can access it while the others 
have to wait. Since these timer based objects do live in the main thread 
of the application and the other side reading the buffer is within a 
thread I assume that a critical section would do? Because after reading 
he has to delete what he read. The list is a TStringList by the way.
Is this idea okay, or will I run into trouble with this? If yes, where 
and how to avoid it?

The only downside I can currently find is, that without threads it won't 
scale very well on multicore CPUs. But right now this isn't a big 
problem I think.


To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be

Reply via email to