[Lazarus] lnet sockets, ´"eventer"

[Michael Schnell]

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