unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
* 'make-comint' question
@ 2013-07-31 11:42 Thorsten Jolitz
  2013-07-31 12:44 ` Tassilo Horn
  2013-07-31 14:44 ` Stefan Monnier
  0 siblings, 2 replies; 8+ messages in thread
From: Thorsten Jolitz @ 2013-07-31 11:42 UTC (permalink / raw)
  To: help-gnu-emacs


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




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: 'make-comint' question
  2013-07-31 11:42 'make-comint' question Thorsten Jolitz
@ 2013-07-31 12:44 ` Tassilo Horn
  2013-07-31 13:51   ` Thorsten Jolitz
  2013-07-31 14:44 ` Stefan Monnier
  1 sibling, 1 reply; 8+ messages in thread
From: Tassilo Horn @ 2013-07-31 12:44 UTC (permalink / raw)
  To: help-gnu-emacs

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




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: 'make-comint' question
  2013-07-31 12:44 ` Tassilo Horn
@ 2013-07-31 13:51   ` Thorsten Jolitz
  0 siblings, 0 replies; 8+ messages in thread
From: Thorsten Jolitz @ 2013-07-31 13:51 UTC (permalink / raw)
  To: help-gnu-emacs

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




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: 'make-comint' question
  2013-07-31 11:42 'make-comint' question Thorsten Jolitz
  2013-07-31 12:44 ` Tassilo Horn
@ 2013-07-31 14:44 ` Stefan Monnier
  2013-07-31 15:23   ` Thorsten Jolitz
  2013-07-31 17:37   ` Thorsten Jolitz
  1 sibling, 2 replies; 8+ messages in thread
From: Stefan Monnier @ 2013-07-31 14:44 UTC (permalink / raw)
  To: help-gnu-emacs

> 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




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: 'make-comint' question
  2013-07-31 14:44 ` Stefan Monnier
@ 2013-07-31 15:23   ` Thorsten Jolitz
  2013-08-01  3:43     ` Stefan Monnier
  2013-07-31 17:37   ` Thorsten Jolitz
  1 sibling, 1 reply; 8+ messages in thread
From: Thorsten Jolitz @ 2013-07-31 15:23 UTC (permalink / raw)
  To: help-gnu-emacs

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




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: 'make-comint' question
  2013-07-31 14:44 ` Stefan Monnier
  2013-07-31 15:23   ` Thorsten Jolitz
@ 2013-07-31 17:37   ` Thorsten Jolitz
  1 sibling, 0 replies; 8+ messages in thread
From: Thorsten Jolitz @ 2013-07-31 17:37 UTC (permalink / raw)
  To: help-gnu-emacs

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




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: 'make-comint' question
  2013-07-31 15:23   ` Thorsten Jolitz
@ 2013-08-01  3:43     ` Stefan Monnier
  2013-08-01  7:58       ` Thorsten Jolitz
  0 siblings, 1 reply; 8+ messages in thread
From: Stefan Monnier @ 2013-08-01  3:43 UTC (permalink / raw)
  To: help-gnu-emacs

> 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




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: 'make-comint' question
  2013-08-01  3:43     ` Stefan Monnier
@ 2013-08-01  7:58       ` Thorsten Jolitz
  0 siblings, 0 replies; 8+ messages in thread
From: Thorsten Jolitz @ 2013-08-01  7:58 UTC (permalink / raw)
  To: help-gnu-emacs

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




^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2013-08-01  7:58 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-07-31 11:42 'make-comint' question Thorsten Jolitz
2013-07-31 12:44 ` Tassilo Horn
2013-07-31 13:51   ` Thorsten Jolitz
2013-07-31 14:44 ` Stefan Monnier
2013-07-31 15:23   ` Thorsten Jolitz
2013-08-01  3:43     ` Stefan Monnier
2013-08-01  7:58       ` Thorsten Jolitz
2013-07-31 17:37   ` Thorsten Jolitz

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).