Welcome, Guest. Please login or register.

Author Topic: Is there a convention for Break signals other than C?  (Read 6519 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline NinjaCyborgTopic starter

Is there a convention for Break signals other than C?
« on: February 16, 2021, 07:42:36 PM »
So the convention for C signal is 'stop what you're doing and exit' and D signal is I think 'stop your batch job after the current step completes' but has there ever been a convention for what the E and F signals should do?
 

Offline NinjaCyborgTopic starter

Re: Is there a convention for Break signals other than C?
« Reply #1 on: February 16, 2021, 07:57:56 PM »
Yes I read that and see that it doesn't say what D, E and F should do, but that doesn't mean there hasn't been some unofficial convention in the past, or attempts at one.

But thanks for posting a somewhat helpful answer for a change. Since you have a view on everything what would you think would be useful? Show/Hide a GUI? Switch between quiet output and verbose output on the receiving processes stderr? some kind of 'confirm you haven't crashed please' heartbeat? release any memory you're not using if you can?
 

Offline NinjaCyborgTopic starter

Re: Is there a convention for Break signals other than C?
« Reply #2 on: February 17, 2021, 02:19:37 PM »
Thanks.

While 'reload new settings' is an interesting one I think it could be argued the proper way to do that is the IPrefs way, to monitor the file and automatically reload settings when it changes.

Taking the 'service manager view' one can also argue that instant update is not ideal for all use cases, manually edited settings files might have mistakes in them that should be validated or tested first, so in the case of a TCP stack I can see why it they've done it as an explicit reload. For something like a TCP Stack you don't necessarily want it to load new settings implicitly as that could break in-progress connections, and neither do you want to exit and relaunch it as that's a heavyweight activity compared to a reinitialise, since it wouldn't need to close and reopen libraries, free and reallocate memory, and apps that depend on it might not need their existing resources terminated. So a soft-reset function is desirable for 'server'-like use cases. Not that AmigaOS runs many servers and services in the normal sense.

It seems like we have
Ctrl C - terminate immediately
Ctrl D - terminate at end of your current job
Ctrl E - not allocated
Ctrl F - reinitialise yourself but don't exit

I'd vote for Ctrl E being a 'confirm you are there' signal which the correct response is to send a Ctrl E signal back to the process you received it from. In this way a task manager could ask software to confirm to hasn't crashed or stuck in a busy loop. Or alternatively it could be used for asking a process to yield or reduce it's own task priority perhaps because it's using too much CPU. But then, the OS can do that arbitrarily.
 

Offline NinjaCyborgTopic starter

Re: Is there a convention for Break signals other than C?
« Reply #3 on: February 17, 2021, 03:23:50 PM »
True true, it's just a thought exercise my friend. No one's trying to dictate anything. Thanks for pointing out Sashimi, I had forgotten it. One could argue Sashimi is following that pattern - Ctrl D - finish your current activity and reset yourself, Ctrl - F end what you're doing and reinitialise yourself. Admittedly the difference between those two is subtle.
« Last Edit: February 17, 2021, 03:25:00 PM by NinjaCyborg »
 

Offline NinjaCyborgTopic starter

Re: Is there a convention for Break signals other than C?
« Reply #4 on: February 18, 2021, 12:31:49 PM »
I think everybody here already knows that.
 

Offline NinjaCyborgTopic starter

Re: Is there a convention for Break signals other than C?
« Reply #5 on: February 21, 2021, 02:35:11 PM »
Stop being a dick.
 

Offline NinjaCyborgTopic starter

Re: Is there a convention for Break signals other than C?
« Reply #6 on: February 25, 2021, 10:40:16 AM »
I noticed using Ranger than several OS4 system processes listen to ctrl E and Ctrl F. Not sure what for.