Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Iridium Banner AMIStore App Store A1200/A600 4xIDE Interface

AuthorTopic: Is there a convention for Break signals other than C?  (Read 2557 times)

0 Members and 1 Guest are viewing this topic.

Offline NinjaCyborg

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 kolla

Re: Is there a convention for Break signals other than C?
« Reply #1 on: February 16, 2021, 07:47:31 PM »
https://wiki.amigaos.net/wiki/Exec_Signals

Quote

SIGBREAKB_CTRL_C
The SIGBREAKB_CTRL_C signal bit is used extensively as the general purpose "Break" signal. It is used by all shell handler commands and many applications to invoke a normal exit of the program. It is up to all applications to follow this recommendation.
Applications should never crash or generally misbehave when receiving a SIGBREAKB_CTRL_C signal bit from any source.

SIGBREAKB_CTRL_D
The SIGBREAKB_CTRL_D signal bit is used mostly by the shell handler to stop execution of a script file or non-interactive stream. It may also be used by applications.
Applications should never crash or generally misbehave when receiving a SIGBREAKB_CTRL_D signal bit from any source.

SIGBREAKB_CTRL_E
The SIGBREAKB_CTRL_E signal bit is not currently used by the shell handler but may be used by some other handlers, OS subsystems or multi-process applications for general undefined inter process signalling.
Applications should never crash or generally misbehave when receiving a SIGBREAKB_CTRL_E signal bit from any source.

SIGBREAKB_CTRL_F
The SIGBREAKB_CTRL_E signal bit is not currently used by the shell handler but may be used by some other handlers, OS subsystems or multi-process applications for general undefined inter process signalling.
Applications should never crash or generally misbehave when receiving a SIGBREAKB_CTRL_F signal bit from any source.

There, now you can yell at me again :)
« Last Edit: February 16, 2021, 07:48:06 PM by kolla »
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline NinjaCyborg

Re: Is there a convention for Break signals other than C?
« Reply #2 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 First Ninja

Re: Is there a convention for Break signals other than C?
« Reply #3 on: February 17, 2021, 02:22:40 AM »
This is a great question, and a much welcomed thread. Although referring to a application hardly implies a set covention, for the sake of the discussion it may be worth noting that the AmiTCP network service responds to CTRL-F, AFAIK, by re-reading its configuration settings. That being said, I'm not sure if any other AmigaOS programs behave the same way.

Offline Spektro

Re: Is there a convention for Break signals other than C?
« Reply #4 on: February 17, 2021, 04:13:24 AM »
According to the Metacomco's "Introduction to Tripos" document (published in 1986) CTRL-E and CTRL-F use cases are documented in the Tripos Programmer's Reference Manual.
...
I just searched the Tripos Programmer's Reference Manual and there were no CTR-E or CTRL-F use cases or examples.

On the Developer CD 1.1/2.1 there is a document (amcx.txt) that says that CTRL-E was initially used as a commodity break key. There are also examples where CTRL-F is used for waking up an application - CTRL-F causes the application to process messages arrived to its message port.
« Last Edit: February 17, 2021, 06:09:40 AM by Spektro »
 
The following users thanked this post: First Ninja

Offline NinjaCyborg

Re: Is there a convention for Break signals other than C?
« Reply #5 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 Thomas

Re: Is there a convention for Break signals other than C?
« Reply #6 on: February 17, 2021, 03:03:47 PM »
You cannot make a convention from just one example.

Ctrl-X signals are for long running shell applications. There are not many of them out there. Usually a long running application either has a GUI or is a commodity.

In pre-commodity times you could have used Ctrl-X signals as easy hot keys.

The only app I know which uses Ctrl-X signals other than Ctrl-C is Sahimi. It uses Ctrl-D to reset the console, Ctrl-E to empty its buffer and Ctrl-F to save the buffer to a file. Just like I said before, easy to use hot keys.


Offline NinjaCyborg

Re: Is there a convention for Break signals other than C?
« Reply #7 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 kolla

Re: Is there a convention for Break signals other than C?
« Reply #8 on: February 18, 2021, 12:28:54 PM »
When you run a script, and want to break it, you typically end up sending ctrl-d + ctrl-c

- ctrl-d tells the shell to break the script and stop running more commands, but the currently running program stays running.
- ctrl-c tells the running program to break and exit.

If you, say, swap it around, and send ctrl-c before ctrl-d, you will break the currently running program, but the script may then just jump on to the next command and your ctrl-d wil just "hang around" till that program is done.
« Last Edit: February 18, 2021, 12:29:56 PM by kolla »
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline NinjaCyborg

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

Offline kolla

Re: Is there a convention for Break signals other than C?
« Reply #10 on: February 18, 2021, 01:01:08 PM »
I think everybody here already knows that.
Good, but sometimes ctrl+c is enough to break the shell script too, and sometimes ctrl+c will _never_ break the shell script.
Does everybody here know the reasons for these cases as well?
« Last Edit: February 18, 2021, 01:01:41 PM by kolla »
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline Steady

Re: Is there a convention for Break signals other than C?
« Reply #11 on: February 18, 2021, 11:45:10 PM »
I would assume because the program responding to Ctrl-C exits with a return code greater than the failat value so the script terminates.
 

Offline kolla

Re: Is there a convention for Break signals other than C?
« Reply #12 on: February 19, 2021, 11:37:24 AM »
I would assume because the program responding to Ctrl-C exits with a return code greater than the failat value so the script terminates.

Correct - except that this doesn't always work.

The shell of OS 3.1.4 has a bug, so FailAt levels are ignored, and scripts will continue regardless, so... make sure to install OS 3.1.4.1 update,  run SetPatch and make sure shell is 46.21 (or newer) before you do anything fancy.

@ NinjaCyborg
Look! I did it again! Another dig at ThoR! :D
« Last Edit: February 19, 2021, 11:41:15 AM by kolla »
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline kolla

Re: Is there a convention for Break signals other than C?
« Reply #13 on: February 20, 2021, 05:16:13 AM »
I think everybody here already knows that.

Looks like buddy Tygre doesn’t understand the difference between ctrl+c and ctrl+d when it comes to script execution - maybe you can explain to him.

https://forum.amiga.org/index.php?topic=75064.msg851630#msg851630
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline NinjaCyborg

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