Bug#575731: [tex-k] tex/pdftex -recorder works incorrectly on parrallel TeX runs (race, breaks make -j)
NP == Norbert Preining writes: it seems that appending a PID number is a wrong idea. users should not do this, since it is documented that the name of the fls file will be derived from the base name of the input file. so this scenario is not a race. ok, i see that appending PID was about the temporary file, before renaming to basename.fls? if so, i apologise. (though there may still be a similar race with the log files) Best, v. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575731: [tex-k] tex/pdftex -recorder works incorrectly on parrallel TeX runs (race, breaks make -j)
NP == Norbert Preining writes: As can bee seen both tex/pdftex first use intermediate temporary file (tex.fls / pdftex.fls) and only then rename it to $(jobname).fls So the problem here is that when I try to compile both 1.tex and 2.tex _simultaneously_ (e.g. through make -j2) there is a good chance that both tex runs will open the same pdftex.fls and then oops, resulting .fls will be wrong. I wonder, how it is different from log files? when running simultaneously in the same directory tex 1.tex and pdftex 1.tex, the log file 1.log will be wrong as well as the fls file. i.e. if there's a race with fls files, there's the same race with log files. it seems that appending a PID number is a wrong idea. users should not do this, since it is documented that the name of the fls file will be derived from the base name of the input file. so this scenario is not a race. Best, v. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575731: [tex-k] tex/pdftex -recorder works incorrectly on parrallel TeX runs (race, breaks make -j)
Hi Vladimir, You are surely right that other filename-related race conditions exist, and that adding the pid to the temp file for fls is merely a palliative, not a fix. However, since that's the case that was reported, and since it was easy to do, it seemed worth doing. That's all. Thanks, Karl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575731: [tex-k] tex/pdftex -recorder works incorrectly on parrallel TeX runs (race, breaks make -j)
Karl,
recorder_name = (string)xmalloc(strlen(kpse_program_name) + strlen(pid_str) +
5);
E
Karl Berry wrote:
I made the change below (this is web2c/lib/openclose.c), let me know if
problems. I hope compilers won't give any guff about the cast and sprintf.
k
--- openclose.c (revision 17609)
+++ openclose.c (working copy)
@@ -37,12 +37,19 @@
static void
recorder_start(void)
{
-/* Alas, while we might want to use mkstemp it is not portable.
- So we have to be content with using a default name... */
+/* Alas, while we'd like to use mkstemp it is not portable,
+ and doing the autoconfiscation (and providing fallbacks) is more
+ than we want to cope with. So we have to be content with using a
+ default name. Throw in the pid so at least parallel builds might
+ work (Debian bug 575731). */
string cwd;
+pid_t pid = getpid();
+char pid_str[MAX_INT_LENGTH];
+sprintf (pid_str, %ld, (long) pid);
recorder_name = (string)xmalloc(strlen(kpse_program_name)+5);
strcpy(recorder_name, kpse_program_name);
+strcat(recorder_name, pid_str);
strcat(recorder_name, .fls);
/* If an output directory was specified, use it instead of cwd. */
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575731: [tex-k] tex/pdftex -recorder works incorrectly on parrallel TeX runs (race, breaks make -j)
I made the change below (this is web2c/lib/openclose.c), let me know if
problems. I hope compilers won't give any guff about the cast and sprintf.
k
--- openclose.c (revision 17609)
+++ openclose.c (working copy)
@@ -37,12 +37,19 @@
static void
recorder_start(void)
{
-/* Alas, while we might want to use mkstemp it is not portable.
- So we have to be content with using a default name... */
+/* Alas, while we'd like to use mkstemp it is not portable,
+ and doing the autoconfiscation (and providing fallbacks) is more
+ than we want to cope with. So we have to be content with using a
+ default name. Throw in the pid so at least parallel builds might
+ work (Debian bug 575731). */
string cwd;
+pid_t pid = getpid();
+char pid_str[MAX_INT_LENGTH];
+sprintf (pid_str, %ld, (long) pid);
recorder_name = (string)xmalloc(strlen(kpse_program_name)+5);
strcpy(recorder_name, kpse_program_name);
+strcat(recorder_name, pid_str);
strcat(recorder_name, .fls);
/* If an output directory was specified, use it instead of cwd. */
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575731: [tex-k] tex/pdftex -recorder works incorrectly on parrallel TeX runs (race, breaks make -j)
recorder_name = (string)xmalloc(strlen(kpse_program_name) + strlen(pid_str) + 5); I knew I was forgetting something obvious. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575731: [tex-k] tex/pdftex -recorder works incorrectly on parrallel TeX runs (race, breaks make -j)
but I wonder, why use intermediate file for recorder at all? Why not to open $(jobname).fls in the first place? Don't want to overwrite the file from a previous run, I suppose. I'm not enthused about using mkstemp (and providing a fallback), but perhaps we can add the pid to the temp file name, or something. Will contemplate. Thanks for the report, k -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575731: [tex-k] tex/pdftex -recorder works incorrectly on parrallel TeX runs (race, breaks make -j)
On 28 Mar 2010, at 22:44, Karl Berry wrote: but I wonder, why use intermediate file for recorder at all? Why not to open $(jobname).fls in the first place? Don't want to overwrite the file from a previous run, I suppose. I also wonder if there are situations where the jobname is not yet known at the time when a filename needs to be recorded. (What exactly gets recorded? Everything *tex opens? If so, using \openin on the command line before \input would probably cause this, for example. Or a pre-\input \font command that causes a .tfm to be read.) JK -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575731: [tex-k] tex/pdftex -recorder works incorrectly on parrallel TeX runs (race, breaks make -j)
On 28 March 2010 Karl Berry wrote: but I wonder, why use intermediate file for recorder at all? Why not to open $(jobname).fls in the first place? Don't want to overwrite the file from a previous run, I suppose. Certainly a bad idea. People expect that it provides information about the last run, even if the program crashed. Whenever you invoke TeX, one of the first thing it does is to open the .log file and overwrites the one from a previous run, and I think that this behaviour is correct and a .fls file from a previous run should be deleted/overwritten too. If \jobname can't be determined before the .fls file has to be opened, a temporary file is needed and your proposal to add the PID to the file name is reasonable. However, PIDs are assigned differently on Unix and Windows. I can't overlook all the implications, but I think I should at least mention the differences. On Unix the PID is incremented whenever a new process is created. On Windows a PID is released when a process is finished and is assigned to the process started next. Suppose that you have a batch file starting two processes: -- tex foo tex bar -- If there are no processes running in the background, they both get the same PID. Regards, Reinhard -- Reinhard Kotucha Phone: +49-511-3373112 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotu...@web.de Microsoft isn't the answer. Microsoft is the question, and the answer is NO. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
