Console output and multithreading

[zim]

Hi
Found some strange behaviour of Writeln in multithreaded app. It's a sort of debug mode (in normal operation it's all in logs), but really annoying.
While on Windows all is ok, I expected use of critical section will help on Linux also, but not helped. Is there any working solution present ?

The problem:

Code: Pascal  [Select][+][-]

1. var Lock: TCriticalSection;
2. procedure Log(S: String);
3. begin
4.   Lock.Acquire;
5.   try
6.     // ... some code with log rotating and output
7.     Writeln(S);
8.   finally
9.     Lock.Release;
10.   end;
11. end;

procedure Log is called many times from different code places, some in main thread, some from child threads.

Expected output:
log1
log2
log3

Actual output under Linux:
log1
           log2
                               log3

[Curt Carpenter]

I would guess it's down to the different line endings used by win (\r\n) and linux (just \n)

[MarkMLl]

I would guess it's down to the different line endings used by win (\r\n) and linux (just \n)

"Staircasing". However I've not seen that happen despite similarly having debug WriteLn()s called by multiple threads.

i) If in doubt, put a Flush(Output) immediately after the WriteLn.

ii) I've never had to use a critical section in that circumstance.

iii) Where are you creating that critical section?

iv) I /have/ seen peculiar effects if mixing references to Output and stdout.

v) The only time I've seen staircasing like that is if I've intentionally messed around with terminal properties using ioctl().

Are you, by any chance, using something like the Crt unit elsewhere in the program? It's generally frowned upon to post a mere fragment, for precisely that reason: people can't see what you're doing before you get to the problem.

MarkMLl

[cdbc]

Hi
I have "Staircasing" galore!
I do use the Crt unit(+incs) and a home-made helper-unit:

Code: Pascal  [Select][+][-]

1. // too big, please see attachment :o)
2.  

Funny thing is, it was running happy along ...and still does 
Yesterday I installed a new kernel in my lappy, upgrade from 5.16.19 to 6.5.13 After that, It all went to H*** in a handbasket when program ends?!?
It ends ok, but back at the prompt, I can't see what I'm typing, and if I type "ls -l" (blind) + enter then the staircasing goes bananas  :'(
I refuse to believe that it has to do with the kernel-upgrade. Regression to 5.16 is not an option, 'cause the new one is a lot faster 
What to do?
Regards Benny

[cdbc]

Have a look-see 
Regards Benny

[MarkMLl]

What to do?

In your case    stty sane    and then start a new thread rather than hijacking this one.

You will probably need to investigate the terminal defaults and what exactly the crt unit is doing on exit. My guess is that if you'd installed that kernel version as part of a new installation there would be something else in the distro handling the terminal differently... systemd is an easy target but there's so much that you're not telling us that it's impossible to say.

MarkMLl

[cdbc]

Hi
No worries Mark, I didn't want to hijack anything, just wanted to show you an example of "staircasing"...
It's the crt unit that's acting up, I'm solving it.
As you were...
Regards Benny

[MarkMLl]

No worries Mark, I didn't want to hijack anything, just wanted to show you an example of "staircasing"...
It's the crt unit that's acting up, I'm solving it.
As you were...

It's something I've seen very rarely since the days of Yggdrassil and kernel v2.x.

MarkMLl

[marcov]

Crashes in the textmode IDE sometimes also cause this.

[MarkMLl]

Crashes in the textmode IDE sometimes also cause this.

Because the kernel hasn't been sent the ioctl() (or sequence thereof) to restore cooked mode. Except for test programs that were deliberately courting this behaviour https://github.com/MarkMLl/serialcomms/blob/main/Term.pas I've really seen this very little over the last 30 years. Except for one particular development environment based on Eclipse... I forget the details, and if they didn't take my bug report seriously then it's hardly my problem.

MarkMLl

[zim]

Actually starcasing is not the only problem. Nearly at the very beginning of my log I constantly see some unicode corription also.
It's quite surprising - every time at the same place and exactly at the same character. Line is somehow broken at that character, and instead of the character an asterisk symbol is shown.
While same output written to the log files has no problems.
Forced Flush has no effect.

So, seems there're still some deep problems with console buffers and it's not thead safe.
Well, I can see the only solution - to make custom class for console output that will do in-memory buffering and a single physical output point.