[Lazarus] FPC 2.6.2 + Thread.Queue?

[Michael Schnell]

On 04/24/2013 04:42 PM, Hans-Peter Diettrich wrote:
> But AFAIK according inter-process communication is very platform 
> specific, dunno what common means the RTL offers for such purposes.

Obviously, the RTL alone can't do it. The dirty details of the 
EventQueue handling needs to be done in the LCL (or at least with the 
LCL in mind), because you need to merge the GUI-events with the internal 
"language" events. ( I understand that with Windows the merging needs to 
take place at the "output" of the EventQueue(s), while with other 
WidgetTypes the merging needs to take place at the "input" of the 
EventQueue(s). )

This is why I claim, that a decent solution needs to introduce 
modifications in the RTL and in all LCL WidgetType implementations (that 
provide GUI-events). (You can take a look at the mse-project that seems 
to have a kind of unified RTL and LCL. here the EventQueues already 
works perfectly on all supported platforms with and without a GUI binding.

I feel that the code for the "Language" event queue needs to be done in 
the RTL (I suppose it already is, because you can use it via 
checksynchronize() ). The LCL WidgetType code thus should not create yet 
another Queue (as it is done right now), but the RTL should enable it to 
merge events GUI form an external Queue (such as existing in Windows) or 
push GUI events in the RTL Queue (supposedly viable for GTK and other 
Widgets)

On top of this decent "full featured" non-GUI WidgetTypes (for 
"embedded" main programs, CGI-programs, Daemons, Windows services, ...), 
and new WidgetTypes (e.g. Browser handled: similar to ExtPascel, ...) 
can much easier be done.

I suppose this is the main problem: for a decent solution a common 
concept for RTL and LCL (i.e. a decent interface-definition based on 
objects) needs to be defined and agreed upon by both core teams, before 
any work can be started. (I fear this never will happen.)

-Michael