timming issues in winboard when game ends and starts

[adams161]

hi,

I am the author of pulsar. I've been having a problem maybe every 1000 games when a game starts and stops suddently. Pulsar peeks at the pipe in search to see if a result has come so it can abort search. its every so many nodes and it happens frequently because my check time and check pipe happen at the same time and since pulsar plays games in artificially low times like 60 ms per move i need to check frequently.

when it finds out its out of time or game is over it aborts the search and gets its move from laat depth it searched. so basicly if not at the root node, cause i dont want to return from the root before picking a move, it does a return once aborts = 0. But i realized that if deep in search it can still go through a number of nodes before it peters out. So today i realized it may actually check the pipe again , since its a low node count tel the next check, even though it doesnt need to but by doing that if a new game started immediatly after it could clean the pipe of some of the initial commands like the new game command, which seemed to happen in one of its last games, cause it never went through new according to the log.

So the fix i implemented was once aborts=1 dont bother to check the pipe again so the data stays there when it gets in to look at the pipe in its normal game loop. Here is my question:

Will winboard ever send result and the new game info at exactly the same time. So if it peaks at the pipe for result it can also have in what it reads from the pipe, new game info which is lost since i dont save info from in search looks at the pipe to the game loop look at the pipe. If there is a small delay from sending result to sending new game i'm ok.

so is this approach going to work?

Mike

[Harald Johnsen]

You can not loose anything if you stop peeking the pipe once timeout is set to true, all the commands are buffered in the pipe.
Another way to do it is to use a setjump() to instantly go back to the root when you have the timeout.

HJ.

[hgm]

How do you peek into the pipe? Normally, asking if there is input pending should not destroy any of the input.

There is no limit to what WinBoard can send between two times that you peek. It can send any sequene of commands until it needs a response from you. If the opponent resigns, it ends the game, sends a result, and might start a new game if you are in match mode. The engine might not even get a time sice from te OS during all that.

If you implemented the ping feature, then WinBoard will not start a new game before pinging you. And then it will wait, if needed for ever, until your engine sends the corresponding pong command. But overlooking the ping would be just as fatal as overlooking a new command: you would hang.

[bob]

You can not loose anything if you stop peeking the pipe once timeout is set to true, all the commands are buffered in the pipe.
Another way to do it is to use a setjump() to instantly go back to the root when you have the timeout.

HJ.

1.. setjump() is not the way to write code. It will make a parallel implementation very complex for no real gain, when it is just as easy to unwind the call stack by something like

if (abort) return(0);

after any recursive call to Search().

2. Losing data isn't the problem he is describing. It is _not_ losing data. So that once a search times out, and something is stuffed in the buffer, you will always get that data, even if you have lost on time and winboard starts a new game. But that data doesn't go with the new game.

this is one of several potential timing holes you have to deal with when using two asynchronous processes to play a game (one is winboard, the other is the engine, communicating through a pipe).

[adams161]

If i implemented teh ping feature and failed to send a Pong for the next game starting would it just hang for that game, but the next game that starts would send a new ping? Or if i miss one ping would my whole session be dead and it would hang on all games tell it was reconnected.

If it just hanged on a given game if it didnt have teh state and respond to ping with pong that would probably be preferable to whats happening now. Currently its sometimes not getting all new game info but managing to make a few moves anyway.

Hanging on a given game is much better if it happens before any moves are made than having it make 2 moves and then hanging. Once it moves the game is rated, if it never moves the game is unrated which makes all the difference in the world as far as the implications of this problem are.

Mike

[hgm]

If you don't send the pong, there will be no next game. WinBoard will just wait forever until it gets the pong. It won't get impatient, and it won't send any new pings.

[adams161]

Can you send pong more times than you need to?

for example i have exactly 2 functions that have the ablity to read the socket, getmove2() used in search and getmove() called in the game loop after every move pulsar makes or after a game ends. Only getmove2 uses peaknamepipe. Getmove in the game loop simply ( whats the word) hangs on read and waits for data and does nothign. so what makes sense is every time i enter getmove in the game loop to send a pong, kind of like hi i'm home and ready for data. Once it goes to read the pipe, since it doesnt peek there, if it missed a ping and no other data is sent it would hang forever. but if it always sends pong before reading there it would be like its saying the door is open come on in as soon as you got something.

Mike

[hgm]

Unexpected pongs are ignored by WinBoard. But you have to be careful: the pongs are numbered. If you did not receive the ping, you won't know wich number to return with the pong. And if it is not the same number, WinBoard will ignore it. (It is full of statements if(lastPing != lastPong) ) So if you send too high a pong number, WinBoard will start waiting as well.

I still don't see how you could overlook input. PeekNamedPipe should only tell you if there is input, not destroy any of it. If you decide to read it, you should not discard any of it, especially not the pings. If you get input that you did not expect, and can't use during the search, you shoud buffer it for later use.

[bob]

If i implemented teh ping feature and failed to send a Pong for the next game starting would it just hang for that game, but the next game that starts would send a new ping? Or if i miss one ping would my whole session be dead and it would hang on all games tell it was reconnected.

If it just hanged on a given game if it didnt have teh state and respond to ping with pong that would probably be preferable to whats happening now. Currently its sometimes not getting all new game info but managing to make a few moves anyway.

Hanging on a given game is much better if it happens before any moves are made than having it make 2 moves and then hanging. Once it moves the game is rated, if it never moves the game is unrated which makes all the difference in the world as far as the implications of this problem are.

Mike

How do you possibly "miss a ping?"

Correct that and the problem goes away.