continuous mode: avoid fsync in writing compilation output

[cridemichel]

in continuous mode (at least in mac osx with vim or macvim or in lubuntu with vim) when a recompilation of latex sources is triggered (e.g. writing the latex file) vim stutters several times (i.e. 3-4 times there are some noticeable lags) and this is rather annoying since I use to save rather frequently my work. The culprit of this odd behavior is the following write inside the function s:callback_continuous_output in autoload/vimtex/compiler/latexmk.vim:

call writefile([a:msg], b:vimtex.compiler.output, 'a')

since a fsync() is invoked after it has been called. This problem can be fixed by adding the "S" flag which prevent a call to fsync() after writing, i.e. by replacing the above line with:

call writefile([a:msg], b:vimtex.compiler.output, 'aS')

I also noticed a similar call to writefile function in s:compiler_jobs.exec(). Maybe is it safer to add the S flag there too?

[lervag]

Thanks, this is quite interesting. I'm not so acquinted with fsync() (or C code and Linux kernel or whatever). What's the drawback of adding the S flag?

[lervag]

In any case, I see from :help 'fsync' that the defaults are different between Vim and neovim. So, the question is if the S flag will lead to unexpected behaviour (e.g. delayed callbacks?).

[cridemichel]

Hi,
I forgot to report that I also gave neovim a try and indeed neovim seems to not have this issue, probably because it does not call fsync() after writing to file. About possible drawbacks according to vim manual:

	When {flags} contains "s" then fsync() is called after writing
	the file.  This flushes the file to disk, if possible.  This
	takes more time but avoids losing the file if the system
	crashes.

hence without the call to fsync() one can loose compilation output after a system crash, but
after a system crash I would not be concerned about this much...

About other possible side effects, I tested already the patch and I can only be happy of it since now vim is much snappier (not to say usable) after saving.

[lervag]

Yes, I read that part. I am inclined to agree that this change should have no ill side effect, and thus that it should be a very good patch. Thanks!

[lervag]

But I think there may be more places where it should be applied. If you do a /writefile, you will find several locations. Should this same patch be applied at these other locations as well?

[cridemichel]

But I think there may be more places where it should be applied.

I also applied the same patch in s:compiler_jobs.exec() and everything is ok so far.
I did not check all places where writefile is called but maybe it is wise to add the "S" flag everywhere to have a real (or more) asyncronous behavior of vimtex.
If you want I can try to apply it everywhere and see...

[lervag]

I'm not sure if everywhere is necessary. But at the similar places of callbacks, and in the corresponding arara.vim, latexrun.vim (if applicable; I don't remember). Feel free to look into it, and if not, I'll also take a look myself when I get the time.

[cridemichel]

I'm not sure if everywhere is necessary. But at the similar places of callbacks, and in the corresponding arara.vim, latexrun.vim (if applicable; I don't remember). Feel free to look into it, and if not, I'll also take a look myself when I get the time.

yes those are the places I meant by everywhere, but I do not use compilers other than latexmk...

[cridemichel]

I have just added the "S" flag to writefile calls pertaining the other compilers (arara, latexrun, etc.) and I also added the "S" flag to the following call:

try
    call writefile([], self.output, 'S')
  endtry

in s:compiler_nvim.exec().
According to neovim manual:

When {flags} contains "S" fsync() call is not used, with "s"
		it is used, 'fsync' option applies by default. No fsync()
		means that writefile() will finish faster, but writes may be
		left in OS buffers and not yet written to disk. Such changes
		will disappear if system crashes before OS does writing.

hence I think that it as safe in neovim as it is in vim.

[cridemichel]

I have just reverted the extended changes since in some cases are not relevant (the other compilers do not have continous mode) and in one case (the initial writefile) it is not safe to make it asyncronous.
I think that for now it is safe and meaningful just the initial patch (i.e. "S" flag in the writefile in the callback related to continuous mode)

[lervag]

Thanks! I've merged this now, and I'll try to keep this in mind if some similar issue should pop up for a different backend.

[cridemichel]

ok, thank you very much!

[lervag]

You're welcome, and thanks for contributing! tir. 9. mar. 2021, 18:27 skrev Cristiano De Michele < notifications@github.com>:

…

ok, thank you very much! — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#1986 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHT34V7H27O7VBZYEAPKNTTCZLARANCNFSM4Y3CBZGA> .