Le 25/10/2012 09:50, Michael Schnell a écrit :
On 10/24/2012 05:43 PM, Bernd wrote:
It is not clear to me what exactly "the application needs to wait"
should exactly mean in this context.
I think, in a socket-related application, it is rather obvious that the
application needs to wait on data from the socket to arrive. (Same with
Pipes, Async Interfaces, ...)
You got it. This is how the WinCE application runs:
user reacts on a Form
the appropriate form event is lauched
some information is needed from the server before carry on any
further processing
ask the net server:
open connection
send request
wait for answer
close connection
decide what to do next in case of any error
process answer and do whatever has to be done
this means that the application Q cannot be used: the user event method
cannot be exited before the answer to the remote server. The application
is freezed, ok.
And while waiting, the application needs to be able to react on other
"Events" (e.g. those that are generated by the LCL in the standard way
(such as Mouse and Keyboard - generated, TTimer, ... )
that's what I'm looking for
, and that it is
important to reduce Latency and CPU overhead a much as possible,
in my case it dosn't matter if some mili-seconds are spent. It is an
application on hand help devices used in point of sales departments.
to me
the obvious way top go is use a blocking read in a thread and have the
thread insert (mix with the other events) a main thread event by
QueueAsyncCall (which is platform independent and created exactly for
that purpose).
Right, but does that mean that the lnet cpmponent should be into the
thread range ? Otherwise I don't see how to have the component defined
in the main thread scope and have an event active in an independent thread
Of course in this picture a TTimer can be use to manage receive timeouts
(e.g. close the socket and kill the thread).
Sounds good for me:
wrapper around the TLTcp
includes the working thread
a Timer is set with tth timeout limit
an event is created and reset when request is started
the application enters WaitForSingleObject(Event)
if Timer fires before the thread has terminated,
the event is set
some flag is set showing timeout
if thread terminates in time
data is moved to main thrad space
it sets the event
don't care for buffer share: thread writes it, main app reads only
anf timer does not use it
don't care for event share: whichever comes first sets it
whatever event occurred, thread is terminated and destroyed
-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
