[Lazarus] lnet sockets

[Antonio Fortuny]

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
> Lazarus at lists.lazarus.freepascal.org
> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
>