Le 24/10/2012 15:14, Michael Schnell a écrit :
IHMO, the optimum way to handle waiting on sockets, pipes, asnyc
interfaces and similar stuff is to do a blocking read in a thread, use
QueueAsyncCall() to notify the main thread (i.e. throw an event) when
something has arrived and use a TThreadList (or something similar) to
transfer the data from the worker thread to the main thread.
I know Indy does something like that too. But i'm afraid to go inside.
In my vision, the wait with timeout problem is simply moved into a
thread. The application has still to wait on something to happe.
Because the client application can be blocked waiting for an answer from
the TCP/IP server, it is acceptable that the user waits for something to
happen.
I gonna try to use an Event tied to a timer and the socket receive event.
Event.ReSet;
Socket.SendMesssage;
Timer.Enabled := True;
WaitForSingleObject(Event);
On another hand, when the timer fires, it will execute in the event code:
Event.Set;
and when the socket has received all the message
Event.Set;
Question is: The two pieces of code for the timer(1) and the socket(2)
will they be active when the main thread enters the wait state thru the
WaitForSingleObject ?
No problem for the timer, it is the OS responsiblity to run, but the
socket ?
The last idea is to move the socket into a thread so it can run
independently of the application and set the Event when either all data
has benn rea od the timer fires.
I do know that this works fine with Windows and Linux.
I have no idea about CE (and never will).
-Michael
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
