[Lazarus] Using Lazarus for non-graphical apps

[Mark Morgan Lloyd]

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 
"authentic".

-- 
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]