[fpc-pascal] lnet for TCP daemon

[Marco van de Voort]

In our previous episode, Michael Schnell said:
> OK, so "checksynchronize()" is the correct name of the RTL-provided 
> function that pulls the event queue. (Sorry that the correct name 
> escaped from my silly brain.) 

Yes, it is the connection between VCL and RTL for this kind of stuff.

> AFAIU this supposedly is not platform-dependent, but simply pulls the
> queue and calls the event handlers as sub-functions of checksynchronize(). 
> (I need to check the sources ASAP...)

It blocks for a maximum time on the event.

> Did I understand you correctly that there is a "notifying" procedure, 
> that is called by the Event queuing mechanism each time an event is 
> pushed onto the queue ?

That was not me, but Sven or sb else. But as I understood it, the queue
method does that internally(thus platform dependent). He never said it was a 
public option. You trigger it by queue()ing or synchronize()ing.

> This procedure then would potentially be called from Worker threads and
> thus here, we need use the OS to schedule the (later to be done) queue
> poll by the main thread via checksynchronize().

No. The mainthread simply should always loop around checksynchronize while
idle. Checksynchronize is the delay in the event loop so to say, by blocking
on some internal event. Thus if something is queued, the event is triggered
and the mainthread will wake up immediately (if it was indeed blocked on
checksynchronize)

> Obviously the LCL needs to use both procedures to merge the RTL's event 
> queue with the queue it handles the GUI events in.

 
> Obviously a non-LCL based user code can implement it's own OS-depending 
> mechanism to schedule a call to checksynchronize() triggered by the said 
> "notifying" procedure.

The non-LCL one must simply call checksynchronize as the blocking part of
the mainthread's eventloop. 
 
> The "hope" I expressed in the recent mail was, that the RTL might allow 
> for enabling the described OS-depending Thread to MainThread scheduling 
> mechanism, so that any user code does not need to implement it new with 
> each project (but just set an enable flag or something similar).

See above. It is there, there is no LCL dependence in theory, but other
eventloop systems might assume they themselves implement the blocking part.
(e.g. to wake up because of OS messages)

Services, console network server implementations etc probably already do
that both on Delphi and Lazarus.