Mattias Gärtner wrote:
Zitat von Graeme Geldenhuys <grae...@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
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
