Carbon (macOS) port asks about killing stderr buffer

[David Edmondson]

On Thursday, 2017-10-26 at 12:32:17 +0100, David Edmondson wrote:

> After the changes to use `make-process', the Carbon port of emacs on
> macOS (often referred to as emacs-mac or the railwaycat port) will ask
> about killing the stderr buffer after any `notmuch-search':
>
> Debugger entered--Lisp error: (quit)
>   yes-or-no-p("Buffer \" *notmuch-stderr*-839121\" has a running process; kill it? ")
>   process-kill-buffer-query-function()
>   kill-buffer(#<buffer  *notmuch-stderr*-839121>)
>   notmuch-start-notmuch-sentinel(#<process notmuch-search> "finished\n")

This happens on the current version of OpenIndiana (a fork of a fork of
a fork of a fork of Solaris) as well when running:

(emacs-version)
"GNU Emacs 25.3.1 (i386-pc-solaris2.11, GTK+ Version 2.24.31)
 of 2017-09-12"

> A quick look at the implementation of `make-process' in the Carbon port
> didn't reveal anything obvious to me. This mostly seems like a race -
> whether emacs has decided that the process associated with the stderr
> buffer is dead or not when we call `kill-buffer'. Is any ordering
> guaranteed by the implementation?
>
> I _think_ that have also seen the same problem when asynchronous address
> harvesting is happening for completion on the default NextStep port for
> macOS, but haven't been able to reliably reproduce it.
>
> dme.
> -- 
> I got a girlfriend that's better than that.

dme.
-- 
So think of Bob and Judy, they're happy as can be.