[Lazarus] nonlcl basic issue: is codetools LCL dependent?

[Mattias Gaertner]

On Fri, 27 Jun 2014 10:35:28 +0200
Michael Schnell <mschnell at lumino.de> wrote:

>[...]
> > So? Program a queue.
> 
> IMHO this is not appropriate.
> 
> There already is a queue in the RTL that needs to be handled, as same is 
> fed by TThread.Synchonize (and TThread.Queue) user accessible functions.
> Hence an additional queue would need merging the queue outputs and 
> handling the waiting and waking for both Queues simultaneously. This 
> (waiting and waking regarding the additional queue) needs arch depending 
> code (as done in the GUI based Widget Types).

That's not arch dependent, but library dependent.
In case of nogui there is no library, so you have the full control.


> But the NoGUI Widget Type 
> is done for small embedded projects. 

Not quiet. The nogui widgettype is for LCL applications running without
GUI. This can be a daemon or console tool.
Because the LCLBase is not optimized for smart linking it pulls in a lot
of stuff and it is not good for small embedded projects.


> here arch-independence, low latency and low processor demand is critical.

Have you actual numbers of the overhead that you fear so much?

 
> >> They implement a second queue besides the one the RTL implements for
> >> TThread.
> > Probably they have several.
> 
> IMHO it is not a very nice concept to merge queue outputs. This of 
> course has historical reasons with the existing GUI based widgets sets.
> 
> IMHO it would be better top merge the queue inputs and hence waiting and 
> waking is central.
> 
> (A concept to do this would be a central Event Queue implementation in 
> the RTL that always is used by the LCL Widget sets. Of course with the 
> Windows widget set this technically can't be done, as you need to use 
> the OS Message Queue.

Same for the other widgetsets. Except for nogui.


Mattias