Re: grep-use-null-device

[David Kastrup <dak@gnu.org>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>> `compilation-start' needs to check if the process is running
>>>> before calling `process-send-eof':
>>> 
>>> That's odd.  AFAICT no blobking operation takes place between the
>>> start-process and the process-send-eof, so the process-status should still
>>> be `run' no matter how quickly the process exits (because Emacs shouldn't
>>> process the SIGCHLD it receives until later).
>>> 
>>> What am I missing?
>
>> The process exits during execution of create_process.  The gdb log below
>> with a breakpoint on sigchld_handler demonstrates what really happens:
>
>> Breakpoint 4, sigchld_handler (signo=17) at process.c:6249

[...]

> Oh, I now see that process-send-eof does:
>
>   if (! NILP (XPROCESS (proc)->raw_status_low))
>     update_status (XPROCESS (proc));
>
> which basically copies the asynchronously updated proc->raw_status_* to the
> synchronously updated proc->status.
>
> Since this process status can change asynchronously, adding your test
> for (eq (process-status proc) 'run) before calling process-send-eof doesn't
> fix the bug but just narrows the window of the race condition because the
> status can still change between the call to process-status and the call to
> process-send-eof.
>
> So I suggest the patch below instead,

[...]

> +	      (when compilation-disable-input
> +                (condition-case nil
> +                    (process-send-eof proc)
> +                  ;; The process may have exited already.
> +                  (error nil)))
>  	      (setq compilation-in-progress
>  		    (cons proc compilation-in-progress)))
>  	  ;; No asynchronous processes available.

I think it is the wrong fix to just ignore an error which should not
occur in the first place.  Rather process-send-eof should be fixed not
to throw an error as long as the process is not considered dead from
Emacs' point of view.  That there is nobody to actually look at the
eof can't be considered a problem in asynchronous operations: the
consuming process can close down without waiting for an explicit eof.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum