[Lazarus] Multi-threading support in IDE

[Martin]

Mattias Gärtner wrote:
> Zitat von Graeme Geldenhuys <graemeg at opensoft.homeip.net>:
>
>> Martin Schreiber wrote:
>>>> From the MSEide config dialog, I gather MSEide also launches the
>>>> FPC compiler in a separate process and not built into the MSEide?
>>>>
>>> Yes. It can also call gcc and parse the error messages. Also possible
>>
>> So how did you resolve the async process issue that Lazarus is 
>> experiencing under Linux? Or does running the compiler process 
>> (TProcess style) via a separate thread bypass the issue of 
>> TAsyncProcess that Lazarus IDE is using. That means MSEide doesn't 
>> need a TAsyncProcess type component?
>>
>> If so... Mattias, could Lazarus IDE be modified to run the compiler 
>> TProcess in a separate thread. And then another thread which filters 
>> the compiler output to the Messages window. Or is that a huge task?
>
> No. Just write a ThreadedProcess. That would work pretty much like 
> TAsynProcess.
> And I guess it will suffer the same bug.
I don't know what you mean by "ThreadedProcess" unless you meant yes, 
but wanted to indicate a different form of implementation?

IMHO, if the process running fpc is started from a different thread, 
then the IDE can be kept as functional, as it can with TAsyncProcess.
In fact if the TProcess is in started from a thread of it's own, it does 
not want to be Async, it wants to be blocking, so you don't need to put 
a lot of sleeps into your code.

As separate thread *can* also solve one more issue.

Currently  even the AsyncProcess is done in a loop. It does use the 
OnDataRead event, but only to fill a cache, which is then used in a loop.
It should not be in a loop at all. It should be purely event driven. 
Then it would continue to run, even if a "search in files" is started 
while compiling....

If you create a class TThreaded Process (just to simulate an 
AsyncProcess within a (hidden) Thread), then you still must transform 
the current loop into an event driven model.


However this 2 issues can be addressed on their own. even using a 
blocking thread, you can go (almost) event drive. Put the read on a 
timer (every 10 milliseconds) or OnIdle, The read will block, but after 
each read, it will return to the event loop => events will be processed 
normally (instead of ProcessMessages), and then the next read happens on 
timer, or idle


In fact if you make everything eventdriven, then you could introduce 
some method to mark events as thread-save, and the event-loop could 
automatically deploy threads, if a lot of events occur => that would be 
cool.

Martin