console/terminal on program exit

Linux specific questions.
speedfixer
Posts: 606
Joined: Nov 28, 2012 1:27
Location: CA, USA moving to WA, USA
Contact:

Re: console/terminal on program exit

Post by speedfixer »

But you have been a help, many times.
Thank you.

I learn with each exchange.
You have an eye for detail.
A passion for precise, I expect.


I have a way that works.
FB isn't perfect - won't be soon. But I like it.

david
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: console/terminal on program exit

Post by caseih »

speedfixer wrote:I can accept that FB still has problems with threads.
Everyone has problems with threads. The problems you are experiencing are very common with threaded programming. Even code that's properly synchronized with primitives like mutexes and semaphores. This is why asynchronous programming techniques are becoming so widespread.
The kill $PPID corrects the terminal status - for me - seemingly without repercussions as far as I can tell. (It is now 'kill -15 $PPID' as I have read more about kill in linux.) This works local, remote, and from windows into linux (I only program in linux.) It is an FB problem, not how I use the language. Avoiding the problem doesn't make it go away. Terminal and console routines in FB are regulary rewritten and adjusted as problems surface. I read DEEP into the forums before I post a question. And I make simple stupid mistakes, too, like anyone else.
I can see how you are arguing that there's a bug in FB's runtime , but that's not really the case. Something not being thread-safe does not mean it's buggy. You just just have to work with the limitations of things being not thread-safe. All you can do is avoid the problem. And then in fact it has gone away! :)

Did you ever try replacing all calls to shell() with open pipe? That will eliminate any and all messing with the tty.
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: console/terminal on program exit

Post by fxm »

I hoped at least that putting 'Shell(...)' inside a mutex locked should allow to suppress 'Sleep 10' in the 'For' loop that creates the threads!
speedfixer
Posts: 606
Joined: Nov 28, 2012 1:27
Location: CA, USA moving to WA, USA
Contact:

Re: console/terminal on program exit

Post by speedfixer »

I use each to spawn, or query the system.

I test each - every time. And then have to change it later, and then change again.
At least the explanation from dkl helps to me understand the scope of the issue.
I don't expect this is the end of the topic - but I don't expect full correction any time soon.
I can live with what I have now.
I expect i will have to explore querying the PID of processes to achieve some better reliability. But that's for another day. I can make my stuff work now.

I do have some programs that spawn programs that fork to others that ...

At the moment: full cluster control, program version management, system role assignment, system performance assesement.
Its been fun. Keeps me busy.
speedfixer
Posts: 606
Joined: Nov 28, 2012 1:27
Location: CA, USA moving to WA, USA
Contact:

Re: console/terminal on program exit

Post by speedfixer »

@fxm:

"Remark: mutex use inside sub rmp_putpingtable() is useless because each thread has its own array element."


Question:

Does this mean that there can NOT be a collision with a lot of threads writing back to the same array, different elements?



david
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: console/terminal on program exit

Post by fxm »

Yes, if each thread has its own array element (in read/write), there is no risk of collision:
- Each thread reads the array descriptor to get the array location in memory and deduce the address of its own array element by an offset in memory.
- This descriptor access common to all threads being only in reading mode for all, there is no risk of any polluted reading.
- Therefore putting a mutex is useless and even penalizes the execution time.
speedfixer
Posts: 606
Joined: Nov 28, 2012 1:27
Location: CA, USA moving to WA, USA
Contact:

Re: console/terminal on program exit

Post by speedfixer »

This problem should be called:

fail to reset console properly on return from graphics window (in Linux)

Thread fixes in the interim have improved the original problem I reported.

I recently discovered another cause of this problem.

I hit this trouble again - chased it a little bit - again.
Tried a completely different console program. Previous was lxterminal - this time I tried mrvxt. Same thing.
Played with it some more.

I found that using the close command with a file number of 0 (zero) terminated my program.
My other destructors didn't run past this point, either.
An error catch immediately following the offending line did not catch it. All FB libraries and the main program were compiled with -exx.

Fix:
I simply tested that this close command file number = 0 to bypass - and all was well.

Just some info for anyone that hits this problem.


David
speedfixer
Posts: 606
Joined: Nov 28, 2012 1:27
Location: CA, USA moving to WA, USA
Contact:

Re: console/terminal on program exit

Post by speedfixer »

Still have this problem occassionally - user threads or no user threads.

I think it is just some complexity in Linux in correctly resetting the console/terminal when the graphics close.

I am now using:

Code: Select all

        dim as integer fnum, status

        screen 0

        fnum = freefile
        open pipe "tput reset &" for input as fnum
        input #fnum, status
        close fnum
Each of my libraries has a destructor.
Those that MAY use a graphics screen now have this in that destructor sub.
speedfixer
Posts: 606
Joined: Nov 28, 2012 1:27
Location: CA, USA moving to WA, USA
Contact:

Re: console/terminal on program exit

Post by speedfixer »

Problem is clean/functional console/terminal on exit in Linux (Lubuntu, mostly.)

My source and results are all on remote systems. Only geany and FB is local.
I have a TON of libraries I link static together as needed. When I turn on debug routines, more stuff goes to console. More messed up consoles on exit, even if FB thinks all is well. Then I have to issue a reset (slow) ot tput reset(fast.) Or terminate the console and restart back in the work directory (REALLY slow.)

I still get stuck with messed up term/console screens even though FB thinks it ended its graphics and runtime threads cleanly.
I've given up trying to make *FB* exit better.

The big problem is that FB with the graphics thread doesn't reset its session the best, especially if you sent stuff to the console during your graphics session (open pipe, open cons, etc.) Lots of different terminal/console environments that FB must deal with. That's life. Done fighting.

My programs all exit through a single global sub destructor included automatically at the end of any program. Cleans up any stuff leftover from whatever libs were included.

If the program exits correctly, what works ALWAYS is, last line in global destructor sub:

run("reset")


(These may be only notes for myself, but I started the thread, so this should be the end.)
speedfixer
Posts: 606
Joined: Nov 28, 2012 1:27
Location: CA, USA moving to WA, USA
Contact:

Re: console/terminal on program exit

Post by speedfixer »

Because of later references to this post:

Per last entries:

problem is clean/complete restore of console

General code improvements in FB have reduced the frequency of the problem, but it is still there.

So, a quandry:

If the console is nuked to restore completely, then any previous writes to screen would be gone.

UNFORTUNATELY, I use the console as a debug screen for my (graphics) programs. Blowing out the console isn't a good answer, especially if something is not quite correct in the program. My closing destructors don't blow out the console anymore. They weren't a consistent answer, anyway.

I still have this problem - rarely - but it still appears from time-to-time.
Most frequently (I think), there IS a problem in my code, but VERY rarely does it have anything to do with graphics activity.
At least, as the program matures, the incidence of the poor console restore fades, then is gone with a completed/polished program.
Still a complete mystery about what exactly causes it. I usually forget about chasing the problem in my haste to complete the target program. This can happen with user threaded programs or not.

Currently on 1.09.0
Happens in Ubuntu or Arch flavor Linux OSs; that's all I'm playing with currently.

david
dkl
Site Admin
Posts: 3235
Joined: Jul 28, 2005 14:45
Location: Germany

Re: console/terminal on program exit

Post by dkl »

Yea, I remember that some of the issue was fixed by adding more mutex locking in shell(), exec(), dylibload() around its console cleanup/re-initialization. But even now I'm still seeing problems with a multi-threaded FB program that calls exec() multiple times in parallel. The main problem I'm noticing is that the input echoing in the terminal remains disabled even after the FB program exits.

I think it's because the internal fb_hInitConsole() function will simply capture the current console state (in order to restore it at exit) before applying its custom settings, without checking whether that capture and initialization step was already done before. So it can forget the original tty state and then later tries to "restore" to its custom state, instead of the original. A simple boolean or maybe a refcount should probably fix that... I'll give that a try.

However it still feels like the whole mechanic is just not compatible with multi-threading - as mentioned here many years ago. If one thread temporarily undoes FB's custom tty settings for the duration of a shell() or exec(), another thread using shell() or exec() or even inkey() would have to wait. I don't know how that could be solved.

It would help if the tty state wouldn't have to be temporarily reset for shell() or exec() at all. And/or if the original tty state wouldn't have to be captured at startup, but instead could be assumed to be some default.
speedfixer
Posts: 606
Joined: Nov 28, 2012 1:27
Location: CA, USA moving to WA, USA
Contact:

Re: console/terminal on program exit

Post by speedfixer »

I have several many multi-thread programs. At conclusion, they work ok. Early in a programming cycle, I might have those console problems that don't make sense. Seemingly no relationship to thread closing order, what activity happens in what thread related to the graphics screen, etc. I always spawn the screen in the main thread, and write-to-screen/query-key-status from one control thread. As the code cleans up toward the end, the problems go away. And then I can never pinpoint when/why the trouble cleared.

But I'm careful. All threads are all managed/monitored by the main thread. New threads from child threads are requested through the main. All threads self-terminate; some automatically, most upon request. (I wrote a robust thread management library.) The main won't try to close until the child threads are gone. Othewise, I will get an error log posted.

When I have the faults, I don't get the error messages. I HAVE had gdb tell me a thread didn't close when I had no other errors and my program closed 'normally': I suspect it was the FB rt thread that let my program go and failed to close itself for some reason. This true even in non-threaded programs. In these cases, typically, my destructor sub doesn't run to completion. It starts, but doesn't complete. (Each library has its own exit sub, called by a master destructor sub. Doesn't always die in the same place!) The error that pops when gdb closes the thread is a call to a low-level system thread lib without much info. Since I was usually 20k loc of main deep at that point, AND it was intermittent, I hesitated to stop to chase it. Cutting down that much code to find the trigger wasn't worth the effort. The few times I tried, the fault was gone before I found it. When I finished the program, the error was gone. All the libraries and main were recompiled with -exx -g and no better info at fail.

Generally, can't the main thread have a main process destructor that tracks that console status, and be one of the last destructors executed?

Sure, it is possible to make TSR's, but those are special cases and - as always - one program's at one's own risk. If you want to do something exotic/advanced like that, you should have a clue what dangers await you.
You can't make the world fool-proof.

By the way, I pretty much only 'open pipe' now, whether for OS services, serial/USB use, or running side support tasks. Too much trouble for the other methods. Better to use one tool you know well, than many that you are uncertain about.

If I hit it again, I will try to capture it. I static link against about 80k loc in a couple of hundred functions in 30+ libraries. If you are willing to try I can ship a whole related package set.

I will post here if it happens again. Hopefully, someone is listening at that time.

david
marcov
Posts: 3454
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: console/terminal on program exit

Post by marcov »

I think Dkl's argument is not threads in general, but changing global state (terminal mode) before spawning a console using process. That is somewhat dangerous from a threading point of view.
speedfixer
Posts: 606
Joined: Nov 28, 2012 1:27
Location: CA, USA moving to WA, USA
Contact:

Re: console/terminal on program exit

Post by speedfixer »

speedfixer wrote: Jun 07, 2022 23:34 Generally, can't the main thread have a main process destructor that tracks that console status, and be one of the last destructors executed?
david
dkl
Site Admin
Posts: 3235
Joined: Jul 28, 2005 14:45
Location: Germany

Re: console/terminal on program exit

Post by dkl »

The FB runtime has a global destructor, but unfortunately it's not always the last one, sometimes another FB runtime (in a shared library or another process) ends up being last instead. But yea, multi-threading is also a problem (with regards to the internal state capture and the temporary re-configurations) and the same goes for multi-processing (with regards to the tty device being a shared resource).

Anyways, sounds like you've even seen deadlocks - I've never seen that, so if you have some backtraces or a way to reproduce it that could be useful.
Post Reply