On 10/25/2012 12:31 PM, Bernd wrote:
The eventer that is used by default when putting an lnet component
onto an LCL form is different from the other eventers that lnet
provides. This one is tightly integrated into the LCL and fires its
event from the main thread, just like button clicks and other GUI
events.
Sounds nice.
No sleeping and blocking is required here by your application
and no worker threads.
I suppose you mean "...is required by the user to be handled". That
means that the waiting (here of course not "sleeping", as the "sleeping"
is done in the LCL) is done in some "magical" way in the guts of the
lnet code. This does sound nice. Could you explain how it is done and if
it is done in a _decent_ way (i.e. not performing any polling which
would introduce latency and CPU cycle overhead) ?
All other eventers (select, epoll, kqueue) are only meant to be used
when you explicitly not want the events to be generated by the LCL
main thread,
Good for applications that don't use the LCL and (maybe) for using it in
worker Threads.
These eventers always
block.
That is what I understand an "eventer" does: It blocks until one of the
affiliated events is scheduled.
They have a timeout, so you can make them wake up every x
milliseconds but still they block all of the time.
So the events that can be affiliated are generated by the socket in
question plus a timeout. No more ?
Thats the reason you
should use the existing LCL eventers when you have LCL in your
application,
What do you mean by "LCL eventers" (in fact I already searched the LCL
source code and "eventer" is nowhere to be found).
The only thing I see in the LCL that is an Eventer is the central Main
thread event queue, that calls all event handlers attached to events
generated by GUI, TTimer, TThread.Synchronize, QueueAsncCall,
PostMessage, ...
-Michael
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
