Hooks, concurrency, race conditions

Help
5

So it rejects hooks that have the exact same name and params.

I’m not worried about malicious code, but about my own code, if I use the counter mechanism in a lot of places. For example, here’s a with-tmpfile mechanism:

def defp -params .. %{
  def -override -params .. %arg{@}
} -override

declare-option int tmpcnt
defp with-tmpfile %{
  set -add global tmpcnt 1
  %arg{@} "/tmp/kak_tmp_%opt{tmpcnt}"
  hook -group tst -once add NormalIdle .* %{
    nop %sh{ rm -f "/tmp/kak_tmp_%opt{tmpcnt}" }
  }
}

defp tst-cmd-hist %{
  echo -debug %arg{1}
  echo -to-file %arg{1} -quoting shell -- set -- %reg{:}
  nop %sh{
    . "$1"  # load prologue,  overwrites $@
    echo 1>&2 "Second command was $2"
  }
}

with-tmpfile tst-cmd-hist

This code avoids the issue with potentially limited environ size on various systems, as pointed out by @Screwtapello in a previous topic, by saving them to a temp file (which should be a RAM-only operation) and loading the file inside the shell into shell (not environment) variables.

Regarding the shell, I know it’s a controversial topic. I actually love the shell, as is probably apparent from my posts here. Now, a lot of people say calling the shell doesn’t matter — and it doesn’t, on a desktop, or for infrequent hooks. On a laptop, for “on-every-keystroke”, or “on-timer-msecs” hooks, there’s battery life and thermal (and possibly fan → unbearable noise) to consider.

Also, TBH, it’s fun to figure out how to do things differently :slight_smile: