ZDoom

That's a much better solution than simply adding a timer.

At long last. I'll give it a try soon and make a new post if I encounter any issues.

Should be fixed for good now. The restart may not be triggered from within the dialog box, it may only be done after all subsystems have been shut down.

It was a corrupt config file and the configuration was reset, i've added a check for that and then you can restart again.
https://github.com/drfrag666/gzdoom/commit/a4abebef99d30541a94b62be6eb102aa748a848d
Edit: i've noticed that my post was a bit confusing. What's happening here is that the file is still being written while being read so a lock would be required like Cacodemon345 said but that's not that simple so i agree his solution is okay. Nonetheless i wanted to add several checks to see if the file is a valid config (actually if you load any random text file you'll silently get a factory default configuration which is fine in most cases), that also helps becouse OkayToWrite is false at that point. So i wanted to know what was going on and now i do, if i remember right some people have reported partially reset configurations.

void FConfigFile::LoadConfigFile ()
{
	FileReader file;
	bool succ;

	FileExisted = FileExists(PathName.GetChars());

	if (!file.OpenFile (PathName))
	{
		if (!FileExisted)
			return;
		else
			I_Error ("Could not open config file.\n");
	}

	succ = ReadConfig (&file);
	FileExisted = succ;
}

But where? I've done some investigation and i'm lost here.
I can reproduce it consistently pressing restart but i don't know where the problem is. Some food for thought: after pressing restart several times i can see the config has been reset at the iwad selection startup window. You can see that easily selecting another backend different from the default one and saving the config earlier. Then i've noticed that when you press exit in the picker the config is not saved so when i see that the settings have been reset and exit the config file is not overriden. If i restart again of course i lose my config file.
With my code (but it's the same in GZDoom) i can see putting a Printf that the file is opened succesfully and the succ variable is true every time even when the config is reset. If i remove the read permission from the file before restarting i get the "Could not open config file error message". And it's not something related to saving since i exit without saving and i never get the dialog with the "configuration not saved" error.
[code]void FConfigFile::LoadConfigFile ()
{
FileReader file;
bool succ;

FileExisted = FileExists(PathName.GetChars());

if (!file.OpenFile (PathName))
{
if (!FileExisted)
return;
else
I_Error ("Could not open config file.\n");
}

succ = ReadConfig (&file);
FileExisted = succ;
}[/code]

I know in Windows at least you can easily look up the shares of a file - I am not sure what functions are involved - but if there's any other process that has it open for writing (I think you can check for that too) it can wait for up to 5 seconds for the operation to complete and if it doesn't - then it could error out and tell you it can't read the config file.

But that might not solve the race condition completely.

No, for me it doesn't happen with two instances. Same restarting only one with BDv21 and a bad zscript.txt twenty times in a row.
Edit: just happened now only with the bad zscript.txt.

Two separate instances of Gzdoom launched with broken code produce, with restart of one of them, same result. But that was to be expected.
Day, month, year
"Today" version
[attachment=0]new — копия.png[/attachment]
2051 year version
[attachment=1]new — копия — копия.png[/attachment]

Again, try a more resource intensive mod. It has to unload more stuff when it restarts. That might make it easier to trigger. Particularly a mod with a lot of content.

Precisely, i added a check for file existence but you assume that the file doesn't exist becouse it can't be read. It's a bad habit usually seen in old code.
Are you sure that it cannot happen without pressing the restart button? That said that should be fixed too if it actually happens.

[quote="drfrag"]Interesting but that doesn't change the fact that the original source was wrong and FileExists is broken on windows. When pressing restart with my changes you should still get the config error and be able to investigate the problem.[/quote]
Your proposal won't change anything. The config file does exist, but it cannot be opened for reading because it's already opened for writing.

It's pretty rare when it happens. If anything I'd suggest loading up intensive mods that take a lot of memory for example such as AEons of Death. Maybe it having to unload more may trigger it to occur more often? Just a guess, but perhaps that may cause more overlap.

Okay i can't reproduce it with a bad zscript.txt, even restarting many times.

No, that's to be expected. Sometimes the two processes do not overlap their access, sometimes they do. A classic case of unsynchronized access to a non-shareable resource.

It doesn't happen all the time. Just sometimes. So it's still as enigmatic as any other.