[Lazarus] Using Lazarus for non-graphical apps
Mark Morgan Lloyd
markMLl.lazarus at telemetry.co.uk
Wed Jan 8 10:52:01 CET 2014
Michael Schnell wrote:
> On 01/07/2014 06:11 PM, Mark Morgan Lloyd wrote:
>>> IMHO, the Pascal way of handling such task is using a thread.
>> That's in the main code, not a background thread, and I have good
>> reasons for wanting to do it like that.
> OK. There are decent reasons in certain projects. But Generally the
> "Pascal way" is to do event driven programming. If you do a blocking I/O
> in the main thread, the project is completely idle until the I/O device
> unblocks it. This is not desirable as soon as anything should be done in
> the meantime. That is why it usually is the better way to do blocking
> I/O only in a thread. But if you do that, you mostly need a mechanism to
> notify the main thread about the proceedings in all threads. This is
> only decently handled by an event queue such as provided by
> TThread.Synchronize, TThread.Queue, CheckSynchronize, WakeMainThread, ...
Yes, I know. I must add in my own defense that I'm not "spinning", the
timeout I referred to as "tight" is 100 mSec at which point the main
thread does a quick check whether e.g. one of the emulated I/O
processors (which are each in a thread) has enqueued a message that the
operator needs to know about. In other words, it's "tightly specified to
suit the application", where 100 mSec latency is negligible for a text
program and anything faster would be overkill.
When I put a GUI frontend on it things will obviously be reorganised,
taking into account that driving the GUI is again the main thread's
responsibility. If I put an engineer's panel on it, I'd like the lights
to update very much faster: possibly every 30 mSec.
>> The question was whether I could still use TThread.Synchronize for
>> background threads, which do not in this particular case need a
>> significant amount of OS interaction.
> It does not make much sense to use TThread.Synchronize if the main
> thread can block in any other place than in CheckSynchronize.
It won't. Its responsibilities are limited to interacting with the user
and displaying a limited amount of system state which is maintained by
background threads (2x CPU, 4xIOP, possibly some extra threads for
peripherals emulated over TCP- telnet for attached terminals etc.).
OK, so I admit that I hardcoded a memory test into the frontend code
yesterday. But that's a console function which is only available when
the system's halted, and would not be expected to timeshare. The same
applies to some of the more invasive things that can be done from the
engineer's panel and to reorganisation when a memory module or
peripheral goes faulty or is reconnected: there are some things that
aren't expected to multitask, and where it would not in fact be
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
More information about the Lazarus