Betsemes wrote:Okay, given that information about how to interpret that results string and by looking up the tourney_results.pgn file, I don't find any unfinished game within it. If I open MS Word, copy/paste the results string into Word, highlight the string until the "*" and do a word count, word says there are 94 characters within that portion of the string. If I look up the 94th game, it says black won on time; Crafty 20.14 was playing black while Scorpio 2.7 was playing white. I clearly remember that Crafty crashed once during a game when two instances of Winboard were running. Actually, Crafty is the only one that has given me that kind of problem. Apparently, it does not behave very well when the system is busy with other tasks. At that particular time, I closed the offending winboard instance and run it again; but Crafty kept crashing on the second window, this time not running games at all (Crafty still was running on the other window). So I settled for keeping one winboard window open while Crafty was running. When Crafty finished its games, I reopened the second winboard window without problems.
The funny thing is that no game seems to have finished strangely, all of them show a game result.
There is something funny here, if I assume one character on that results string represents one game played, then something doesn't add up. If I open Tourney_Results.pgn on Winboard, it says there are 149 games on it (Scid confirms this games count), but if I do a word count on the results string, it says there are 161 characters without counting the ending space (a space actually ends the string after that ending asterisk) and I confirmed it by counting them myself. It seems that there are 12 games that were not stored. If we discount the asterisks, that makes 10 lost games. Where are them? Are there any known bugs on the way the games are stored? Is it possible that some games were not stored while their results were recorded on the tourney file results string? What if both instances of WinBoard attempt to access the pgn file at the same time? What would happen?
It should be protected against that. Even if the protection fails, the effect should be that the games get merged. If I understand correctly how writing of files in 'append' mode works, it should never be possible to lose data. But I included code to lock the first 100 bytes of the file for exclusive access before a program starts writing, and only unlock after the write completes. Attempting such a lock when another process has already locked it should simply block the program that attempts the new lock, until the other one releases the lock.
But even without all this, the chances of two programs attempting to write at the same time should be really small. Writing the file will take milliseconds, while games take seconds or minutes. So I don't think this can be the problem. The only case I know where WinBoard would not save a game is if the game has no moves (i.e. white forfeits on time). This is intentional.
It could be very illuminating (but alas a bit difficult) to figure out which games are missing. Unless you happened to have the -pgnNumberTag option switched on; in that case all games should have a [Number "N"] tag with a unique sequence number N corresponding to their position in the string. There could be another way, though: I see you played a round-robin of 33 players, with 10 games per pairing and 2 cycles. Each round then has 16 pairings, with 160 games. So the tourney blocked after the first round, meaning all participants should have 10 games. So if you run some cross-table generator on the PGN file, it will be easy to see which are the engines that have missing games. You can then look for the games of those players in the PGN (they should have been played consecutively), and see if they correspond to the sting, and which are missing.
Maybe, I don't remember clearly, but if I did, the "Waiting for other games(s)" message was already being displayed.
In an early version I had a bug there, but I am pretty sure I fixed that (and tested if the fix worked). Indeed quitting WinBoard when it was waiting then forgot to clear the asterisk. This is easy to test, though, in a two-player tournament with 1 game per pairing and many cycles, so I will test it again, just to make sure.
Anyway, I opened the tourney file again now, and that finishing asterisc is still there. Well, it's not a "finishing asterisk" because the string is actually finished by a space. The copy/pasted 'snapshot' within my OP shows this ending space too.
Well, the space at the end is normal: at some time you had two WinBoard instances playing on the tourney, and they would both reserve a next game (so the string would end with **), but they would both discover that the first available game was for round 2, while there was still a result missing from round 1. So they would start to wait for that. But then, when you quit them, they would replace the asterisk for the game they reserved by a space, so the string would end in two spaces. When you again start a WinBoard, it grabs the first of the two spaces as the game to reserve, but again it sees that it is of round 2, and round 1 is not yet finished. But it will already put the * there, to indicate it is reserved, preventing another WinBoard instance to reserve that game too.
EDIT:{I have an idea of what may have happened here. The ending two characters are "* ", an asterisk and a space. The last time the tourney run, both windows were displaying the "Waiting for other games(s)" message. So I find reasonable to think that by that time, two asterisks were at the ending of that string, one for one of the winboard instances, and the other one for the other. Now when I closed the first one, It replaced the last asterisk with a space, and when I closed the other one, it replaced the last character within the string with a space too without checking whether or not it was an asterisk or a space. That would have wrongly left the penultimate asterisk there since both instances only cared for the last character within the string. Just an idea, you know better than me how your program works.}
No, it should not work that way. When replacing the * with space or a +-= result, they count from the beginning, not from the end. They know the sequence number of the game they picked (they need that to convert it to a pairing, to know which engines to load). When a game finishes, they lock the tourney file, read it, count the number of characters in the result string (including all spaces), calculate where the beginning of that string would be w.r.t. the end of the file, seeks there, makes really sure it is at the right place by reading and checking the leading quote (there is some fuzziness there, because line endings can be CR+LF or just LF), and from that place on writes out the result string it read in its entirety (after it made the update of the game result with the reserved sequence number. Only then it unlocks the file,so other WB instances could use it to reserve the next game, or write a result.
