On 10/25/2012 10:42 AM, Antonio Fortuny wrote:
Right, but does that mean that the lnet cpmponent should be into the
thread range ?
I don't really know in what way lnet can help you, but if it does not
use LCL events or GUI stuff, it should be no problems to use it in a in
thread. Or you could just extract the code pieces that might be useful
for you and implant them in your own code.
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
_Defining_ a component has nothing to do with the thread context is is
going to _run_ in. (e.g. TThreadList.Create usually is called in the
main thread while e.g. the Add procedure obviously is meant to
be called in a worker thread. ) So I suppose you can Create an lnet
instance wherever you want and call the function that results in a
(blocking) read of the socket in a thread. (But as always with thread
you need to be aware of stuff that can't be concurrently used and
protect this with critical sections.)
Sounds good for me:
I hope for the best.
(But OTOH, I am not sure that things like QueueAsyncCall are correctly
implemented with the CE version of the LCL. I did test them with Windows
and KDE. I do have a testing project for this kind of thread communication.
data is moved to main thrad space
You don't actually need to _move_ the data, you just need to take care
that mutual access is decently handled.
You can
Thread:
- create a buffer (e.g. creating a data holder object or using alloc() )
- fill the buffer
- push the pointer in a TThreadList
- create the event
- don't ever access this instance of the buffer
Main Thread
> Event-Handler:
-->
- is TThread empty then exit
- pull the pointer from the TThreadList
- handle the Data
- free the buffer.
- loop to -->
-Michael
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
