Command_fifo bugs?

Complaints & Improvements
1

Did anyone play with command_fifo? It seems… fragile, if not utterly broken. I can update a buffer via the command fifo only with liberal use of sleep, not sending eval -draft to kak, not relying on response_fifo (reading from it can result in an interrupted system call; then, if the shell process retries, a hang).

The only reproducible thing I have right now is

nop -- %sh{
  set -ue
  i=9000
  while :; do
    i=$(( i - 1 ))
    [ $i -ge 0 ] || break
    #echo 1>&2 $i
    echo >"$kak_command_fifo" 'echo -debug hi'
  done
}

which, after being sourced a couple of times, eventually leads to a SEGFAULT. With valgrind, I can trace it back to event_manager.cc:143

              if (it != m_fd_watchers.end())
                  (*it)->run(events, mode);

All this with the 2021.10 release, g++9, g++10 and clang++12

I suppose there is bugwork to be done, but I’m curious if anyone has played with this… interesting feature.

2

Last time I tried it worked flawlessly. I only wrote to the command fifo once though - maybe try that, using a subshell?

3

Yeah. Once works… flawlessly. That’s not very useful though.

4

I have issue using it to raise errors (and stop the flow) and it was not convenient to double wrap evaluate-commands to restore registers with nop.

5

@alexherbo2 I’m not really sure what you mean?

I’ve raised a GH issue; it’s a pitty that this feature is unreliable, as it could be quite elegant and useful.

The problem, of course, is that until closing (and re-opening) the FIFO, kak doesn’t process any commands sent that way.