Repository: neovim/neovim
File: src/nvim/event/proc.c (C)

Code before:
    }
  }
}

/// Performs self-exit because the primary RPC channel was closed.
void exit_on_closed_chan(int status)
{
  DLOG("self-exit triggered by closed RPC channel...");
  multiqueue_put(main_loop.fast_events, exit_event, (void *)(intptr_t)status);
}

static void on_proc_exit(Proc *proc)
{
  Loop *loop = proc->loop;
  ILOG("child exited: pid=%d status=%d" PRIu64, proc->pid, proc->status);

  // TODO(justinmk): figure out why rpc_close sometimes(??) isn't called.
  // Theories:
  // - EOF not received in receive_msgpack, then doesn't call chan_close_on_err().
  // - proc_close_handles not tickled by ui_client.c's LOOP_PROCESS_EVENTS?
  if (ui_client_channel_id) {
    uint64_t server_chan_id = ui_client_channel_id;
    Channel *server_chan = find_channel(server_chan_id);
    if (server_chan != NULL && server_chan->streamtype == kChannelStreamProc
        && proc == &server_chan->stream.proc) {
      // Need to call ui_client_may_restart_server() here as well, as sometimes
      // rpc_close_event() hasn't been called yet (also see comments above).
      bool connected = ui_client_may_connect();
      ui_client_may_restart_server();
      if (ui_client_channel_id == server_chan_id && !connected) {
        // If the current embedded server has exited and no new server is started,
        // the client should exit with the same status.
        exit_on_closed_chan(proc->status);
      }
    }
  }

  // Process has terminated, but there could still be data to be read from the
  // OS. We are still in the libuv loop, so we cannot call code that polls for
  // more data directly. Instead delay the reading after the libuv loop by
  // queueing proc_close_handles() as an event.
  MultiQueue *queue = proc->events ? proc->events : loop->events;
  CREATE_EVENT(queue, proc_close_handles, proc);
}

static void on_proc_stream_close(Stream *stream, void *data)
{
  Proc *proc = data;
  decref(proc);
}


Review comment (suggestion):
if connected=true we would never want to call `ui_client_may_restart_server`, right?

not a blocker for this pr, but just a reminder

Code after:
}

/// Performs self-exit because the primary RPC channel was closed.
void exit_on_closed_chan(int status)
{
  DLOG("self-exit triggered by closed RPC channel...");
  multiqueue_put(main_loop.fast_events, exit_event, (void *)(intptr_t)status);
}

static void on_proc_exit(Proc *proc)
{
  Loop *loop = proc->loop;
  ILOG("child exited: pid=%d status=%d" PRIu64, proc->pid, proc->status);

  // TODO(justinmk): figure out why rpc_close sometimes(??) isn't called.
  // Theories:
  // - EOF not received in receive_msgpack, then doesn't call chan_close_on_err().
  // - proc_close_handles not tickled by ui_client.c's LOOP_PROCESS_EVENTS?
  if (ui_client_channel_id) {
    uint64_t server_chan_id = ui_client_channel_id;
    Channel *server_chan = find_channel(server_chan_id);
    if (server_chan != NULL && server_chan->streamtype == kChannelStreamProc
        && proc == &server_chan->stream.proc) {
      // Need to call ui_client_may_restart_server() here as well, as sometimes
      // rpc_close_event() hasn't been called yet (also see comments above).
      ui_client_may_restart_server();
      if (ui_client_channel_id == server_chan_id) {
        // If the current embedded server has exited and no new server is started,
        // the client should exit with the same status.
        exit_on_closed_chan(proc->status);
      }
    }
  }

  // Process has terminated, but there could still be data to be read from the
  // OS. We are still in the libuv loop, so we cannot call code that polls for
  // more data directly. Instead delay the reading after the libuv loop by
  // queueing proc_close_handles() as an event.
  MultiQueue *queue = proc->events ? proc->events : loop->events;
  CREATE_EVENT(queue, proc_close_handles, proc);
}

static void on_proc_stream_close(Stream *stream, void *data)
{
  Proc *proc = data;
  decref(proc);
}