'make-comint' question

'make-comint' question

[Thorsten Jolitz]

Hi List, 

I erase and save the buffer of an config-file for an external program
before applying 'make-comint on that program, and restore the file to
its old state afterwards:

#+begin_src emacs-lisp
  [...]
  (erase-config-file-for-external-process)
  (set-buffer
   (apply 'make-comint name (car cmd) nil (cdr cmd)))
  (rename-buffer "buffer-name")
  (restore-config-file-for-external-process)
  [...]
#+end_src

When I edebug my code, it does exactly what it should, and the new
inferior subprocess starts without the (unnecessary) configurations
of the erased config file, as it should.

However, when I simply run my code without debugging, the new
inferior subprocess starts _with_ the (unnecessary) configurations,
what seems quite strange to me. 

Is there anything in the code example above that implies that the
execution order of the statements could be different from their
sequential ordering in the source-code?

-- 
cheers,
Thorsten

Re: 'make-comint' question

[Tassilo Horn]

Thorsten Jolitz <tjolitz@gmail.com> writes:

Hi Thorsten,

> I erase and save the buffer of an config-file for an external program
> before applying 'make-comint on that program, and restore the file to
> its old state afterwards:
>
> #+begin_src emacs-lisp
>   [...]
>   (erase-config-file-for-external-process)
>   (set-buffer
>    (apply 'make-comint name (car cmd) nil (cdr cmd)))
>   (rename-buffer "buffer-name")
>   (restore-config-file-for-external-process)
>   [...]
> #+end_src
>
> When I edebug my code, it does exactly what it should, and the new
> inferior subprocess starts without the (unnecessary) configurations of
> the erased config file, as it should.
>
> However, when I simply run my code without debugging, the new inferior
> subprocess starts _with_ the (unnecessary) configurations, what seems
> quite strange to me.
>
> Is there anything in the code example above that implies that the
> execution order of the statements could be different from their
> sequential ordering in the source-code?

What's the definition of `erase-config-file-for-external-process'?
Maybe it erases the config file asynchronously so that `make-comint' is
called before it's erased?

E.g., like in this contrieved example?

(let ((f (make-temp-file "test")))
  (shell-command (format "rm %s &" f))
  (file-exists-p f)) ;; C-x C-e => t

But why should you possibly do that?  `delete-file' should work as does
moving the file away using `rename-file'...

Bye,
Tassilo

Re: 'make-comint' question

[Thorsten Jolitz]

Tassilo Horn <tsdh@gnu.org> writes:

> Thorsten Jolitz <tjolitz@gmail.com> writes:

Hi Tassilo,

>> I erase and save the buffer of an config-file for an external program
>> before applying 'make-comint on that program, and restore the file to
>> its old state afterwards:
>>
>> #+begin_src emacs-lisp
>>   [...]
>>   (erase-config-file-for-external-process)
>>   (set-buffer
>>    (apply 'make-comint name (car cmd) nil (cdr cmd)))
>>   (rename-buffer "buffer-name")
>>   (restore-config-file-for-external-process)
>>   [...]
>> #+end_src
>>
>> When I edebug my code, it does exactly what it should, and the new
>> inferior subprocess starts without the (unnecessary) configurations of
>> the erased config file, as it should.
>>
>> However, when I simply run my code without debugging, the new inferior
>> subprocess starts _with_ the (unnecessary) configurations, what seems
>> quite strange to me.
>>
>> Is there anything in the code example above that implies that the
>> execution order of the statements could be different from their
>> sequential ordering in the source-code?
>
> What's the definition of `erase-config-file-for-external-process'?
> Maybe it erases the config file asynchronously so that `make-comint' is
> called before it's erased?
>
> E.g., like in this contrieved example?
>
> (let ((f (make-temp-file "test")))
>   (shell-command (format "rm %s &" f))
>   (file-exists-p f)) ;; C-x C-e => t
>
> But why should you possibly do that?  `delete-file' should work as does
> moving the file away using `rename-file'...

No, the erasing is done with emacs lisp in a bit lengthy function, but here is
the simple logic in pseudo-code:

#+begin_quote

,------------------------------------------
| Pseudo-code for
| `erase-config-file-for-external-process':
`------------------------------------------

;; rename
rename-file "config-file" to "old-config-file"

;; after renaming, create new empty config file
with-current-buffer find-file-noselect "config-file"
erase-buffer
save-buffer
kill-buffer

#+end_quote

but writing this, I found a possible source of the problem:

,-----------------------------------------------------------------
| (find-file-noselect FILENAME &optional NOWARN RAWFILE WILDCARDS)
|
| Read file FILENAME into a buffer and return the buffer.
| If a buffer exists visiting FILENAME, return that one, but
| verify that the file has not changed since visited or saved.
`-----------------------------------------------------------------

maybe I had an old buffer open that still showed the former content of
"config-file"? But even in this case, there should be a warning, and the
buffer would be erased anyway. 

hmm...strange

--
cheers,
Thorsten

Re: 'make-comint' question

[Stefan Monnier]

> I erase and save the buffer of an config-file for an external program
> before applying 'make-comint on that program, and restore the file to
> its old state afterwards:

> #+begin_src emacs-lisp
>   [...]
>   (erase-config-file-for-external-process)
>   (set-buffer
>    (apply 'make-comint name (car cmd) nil (cdr cmd)))
>   (rename-buffer "buffer-name")
>   (restore-config-file-for-external-process)
>   [...]
> #+end_src

> When I edebug my code, it does exactly what it should, and the new
> inferior subprocess starts without the (unnecessary) configurations
> of the erased config file, as it should.

> However, when I simply run my code without debugging, the new
> inferior subprocess starts _with_ the (unnecessary) configurations,
> what seems quite strange to me. 

The code after `make-comint' is run concurrently with your external
process, so you have a race-condition: if Emacs is quick enough it will
restore the config file before the process gets to read it.


        Stefan

Re: 'make-comint' question

[Thorsten Jolitz]

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

>> I erase and save the buffer of an config-file for an external program
>> before applying 'make-comint on that program, and restore the file to
>> its old state afterwards:
>
>> #+begin_src emacs-lisp
>>   [...]
>>   (erase-config-file-for-external-process)
>>   (set-buffer
>>    (apply 'make-comint name (car cmd) nil (cdr cmd)))
>>   (rename-buffer "buffer-name")
>>   (restore-config-file-for-external-process)
>>   [...]
>> #+end_src
>
>> When I edebug my code, it does exactly what it should, and the new
>> inferior subprocess starts without the (unnecessary) configurations
>> of the erased config file, as it should.
>
>> However, when I simply run my code without debugging, the new
>> inferior subprocess starts _with_ the (unnecessary) configurations,
>> what seems quite strange to me. 
>
> The code after `make-comint' is run concurrently with your external
> process, so you have a race-condition: if Emacs is quick enough it will
> restore the config file before the process gets to read it.

I suspected something like this - thanks for the tip. 

So this is a use case for `sit-for', I would guess ...

-- 
cheers,
Thorsten

Re: 'make-comint' question

[Stefan Monnier]

> So this is a use case for `sit-for', I would guess ...

sit-for sounds here like a recipe to make the race less likely rather
than to eliminate it.

As for eliminating the race, the best option is probably to add
a process-filter and move the "reinstate config file" to the
process-filter, after checking that the process send some output that
indicates that it has read the config file (e.g. a prompt of some sort).


        Stefan

Re: 'make-comint' question

[Thorsten Jolitz]

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

>> So this is a use case for `sit-for', I would guess ...
>
> sit-for sounds here like a recipe to make the race less likely rather
> than to eliminate it.
>
> As for eliminating the race, the best option is probably to add
> a process-filter and move the "reinstate config file" to the
> process-filter, after checking that the process send some output that
> indicates that it has read the config file (e.g. a prompt of some sort).

That sounds like a much better solution, and like the way to go -
thanks.

-- 
cheers,
Thorsten

Re: 'make-comint' question

[Thorsten Jolitz]

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

>> I erase and save the buffer of an config-file for an external program
>> before applying 'make-comint on that program, and restore the file to
>> its old state afterwards:
>
>> #+begin_src emacs-lisp
>>   [...]
>>   (erase-config-file-for-external-process)
>>   (set-buffer
>>    (apply 'make-comint name (car cmd) nil (cdr cmd)))
>>   (rename-buffer "buffer-name")
>>   (restore-config-file-for-external-process)
>>   [...]
>> #+end_src
>
>> When I edebug my code, it does exactly what it should, and the new
>> inferior subprocess starts without the (unnecessary) configurations
>> of the erased config file, as it should.
>
>> However, when I simply run my code without debugging, the new
>> inferior subprocess starts _with_ the (unnecessary) configurations,
>> what seems quite strange to me. 
>
> The code after `make-comint' is run concurrently with your external
> process, so you have a race-condition: if Emacs is quick enough it will
> restore the config file before the process gets to read it.

I suspected something like this, thanks for the tip. Thus a use case for
`sit-for', I would guess ...

PS 
I already followed up to this post, but my last 3 posts on this list
apparently did not get through - did I make it on the spam list?

-- 
cheers,
Thorsten