From: Dave Horsfall <dave@horsfall.org>
To: The Eunuchs Hysterical Society <tuhs@tuhs.org>
Subject: [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55thanniversary
Date: Mon, 13 Mar 2023 14:09:47 +1100 (EST) [thread overview]
Message-ID: <alpine.BSF.2.21.9999.2303131331350.67613@aneurin.horsfall.org> (raw)
In-Reply-To: <20230312222738.bX8Mi%steffen@sdaoden.eu>
[ Followups to COFF, as this is rapidly becoming a Unix tutorial ]
On Sun, 12 Mar 2023, Warner Losh wrote:
> > How often would you call setjmp()/longjmp()?
>
> Cheap enough for occasional error handling, way too expensive for a
> generic exception handling system... processors with lots of registers
> were more of a problem...
I've only ever used it when knee-deep in procedure calls, and I needed to
parachute back to the main loop when things went pear-shaped[*]; failure
was not an option :-)
On Sun, 12 Mar 2023, Steffen Nurpmeso wrote:
> |> How often would you call setjmp()/longjmp()
>
> Only on a Sunday!
Sometimes I did my best work outside of M-F 9-5 :-)
> I never used these myself of free will.
>
> (And never regulary at all until i took maintainership of a BSD Mail
> clone, which is the examplary piece of software to show that BSD signal
> handling and SA_RESTART are a terrible misconception, especially as soon
> as the software gets larger. .. In my opinion. Once it was able to run
> "24/6" i counted the number of system calls necessary for signal block /
> release and installation / removal over a week, and i think the number
> was way in the six digits. System calls them all! I should have taken
> the OpenBSD variant instead, and simply take over what "was good", and
> it would be much, much better by now. They did the work and reduced the
> very messy part to two exactly locatable system call points of interest.
> (I looked i guess 2014-<2017.) A very bad decision. But if i live long
> enough i will make it, and another one i would really long for.)
I've never liked the concept of signals, especially for IPC; it's akin to
being hit over the head with a lump of 4x2. Hardware interrupts were one
thing, but it seemed to be a bit brutal in software.
And no, I don't have an elegant solution short of message-passing.
Heck, I still have nightmares about BSDi's "fdump" program using signals
to coordinate its various children, and completely screwing up my
backups as a result...
> Even on a x86(-32) i have gnashed with my teeth. And that with
> a Cyrix from 1996 .. and not to think about i386 or even earlier
> processors with so few memory and speed.
> I remember _for sure_ looking at the jmpbuf structure by then, and
> the assembler files (sheer magic by then) and x86 instructions.
You can read X86 assembler? I can only do that after a few stiff
drinks... I did buy the book (in order to debug a floating bug defect
in the optimiser -- hey, let's optimise this instruction right out! -- and
I've never trusted optimisers since).
[*]
Cue the saying about it being impossible to design a foolproof system.
-- Dave, the iconoclast
next prev parent reply other threads:[~2023-03-13 3:10 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-09 23:01 [TUHS] I can't drive 55: "GOTO considered harmful" 55th anniversary Steffen Nurpmeso
2023-03-09 23:18 ` [TUHS] " segaloco via TUHS
2023-03-09 23:21 ` Warner Losh
2023-03-09 23:31 ` Luther Johnson
2023-03-09 23:44 ` josh
2023-03-09 23:54 ` Warner Losh
2023-03-10 0:54 ` segaloco via TUHS
2023-03-10 1:08 ` Warner Losh
2023-03-10 10:08 ` Ralph Corderoy
2023-03-10 11:37 ` arnold
2023-03-10 11:56 ` Ralph Corderoy
2023-03-10 11:59 ` arnold
2023-03-10 12:11 ` Ralph Corderoy
2023-03-10 6:15 ` Dave Horsfall
2023-03-10 16:55 ` Steffen Nurpmeso
2023-03-10 17:02 ` Bakul Shah
2023-03-12 20:47 ` Dave Horsfall
2023-03-12 21:50 ` Warner Losh
2023-03-12 22:27 ` Steffen Nurpmeso
2023-03-13 3:09 ` Dave Horsfall [this message]
2023-03-14 19:54 ` [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55thanniversary Steffen Nurpmeso
2023-03-10 1:31 ` [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary Rich Morin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.BSF.2.21.9999.2303131331350.67613@aneurin.horsfall.org \
--to=dave@horsfall.org \
--cc=coff@tuhs.org \
--cc=tuhs@tuhs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).