On 18/4/2011 5:35 μμ, Francois PIETTE wrote:
I think that if you consider what I suggested before, might help you...
It maybe has to do with extra process time the debugger gives
Thanks for insisting.
Which extra process time do you mean ? The debugger has just to be
attached. No need to set any breakpoint nor single step. Just attach.
IMO, when a debugger is attached, the process is not slowed down.
I would also add that there is definetely no CPU time issue, nor network
I/O issue with the application. Every second, it send a single UDP
datagram (A SNMP get request) and expect a single UDP datagram (A SNMP
get reply). A single socket is used for both send and receive and
datagram fits in winsock receive buffer.
When the debugger is attached is it exactly the same like when it's not
attached for the program being executed ?
OK then, my idea was that it's different.
Actually I work with some external hardware devices (USB / serial
connected) that sometimes in the past performed like in the reported
problem and the solution was to give some more available time to the
program with Application.ProcessMessages. But when the debugger was
attached, this solution was not needed and it always worked fine.
Anyway, my approach for the specific problem reported is more generic,
not dealing at winsock level.
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
