[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openbsd-tech
Subject:    Re: Atomic signal flags for vi(1)
From:       Ingo Schwarze <schwarze () usta ! de>
Date:       2021-08-29 18:33:46
Message-ID: 20210829183346.GF38252 () athene ! usta ! de
[Download RAW message or body]

Hi Theo,

Theo de Raadt wrote on Sun, Aug 29, 2021 at 11:38:18AM -0600:
> Ingo Schwarze wrote:

>> *If* more than one GS object ever existed and/or the .gp pointers
>> in different SCR objects could point to different GS objects, this
>> patch might change behaviour.

> If such multiple GS condition ever existed, since signals are (global),
> the handler is only indicating a signal has happened.  And the code
> observing non-zero of these signal-indicating variables would be
> responsible to determine which event it applies to.

Absolutely, that is the sane way to code such stuff.

However, we have all seen signal handlers making complicated decisions
by navigating complex, non-trivial data structures, even in our own
tree.  Of course, those need to be fixed.  But before changing the
code, i still need to figure out whether the seemingly non-trivial
data structure is indeed non-trivial, and which higher-level code
must be made smarter to preserve the functionality, or whether the
apparent complexity merely hides the fact that the data is actually
trivial, as i think it is in this case.

> It is too hard to do this kind of work safely/atomically in a
> signal handler.

100% correct.  And yet, people do try to, and then it even works.
Well, kind of.  Most of the time.  Until it suddenly doesn't.  And
when it suddenly doesn't, people are used to blaming cosmic muons
(and yes, there is indeed about one of those per square centimeter
per minute, on average) rather than thinking something might be
wrong with their code.

Yours,
  Ingo

[prev in list] [next in list] [prev in thread] [next in thread]