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