PeekNamedPipe and testing for console input

[jdart]

I've been using the PeekNamedPipe function for many years to check for input from the chess GUI (Winboard, Shredder, etc.) during a search. This was used in Gnuchess, Beowulf and many other programs previously.

Lately though I have seen some cases running Windows XP x64 on a 4-core box where the engine is not "woken up" by input from Winboard.
It is pondering and I see debug output from the ponder search in the log, so the search is not stopped or hung. The sampling interval for input is reasonable. But the Winboard log shows data coming in and it is never read. This is a sporadic problem. Usually it's ok but maybe once a day on ICC I'm seeing this issue.

There are some reports of problems with PeekNamedPipe under Windows XP, in a multi-threaded environment, see for example:

http://msdn.microsoft.com/en-us/library ... S.85).aspx

http://www.duckware.com/tech/peeknamedpipe.html

But this doesn't seem exactly relevant (and it is reportedly fixed now).

I'm not clear this is a Windows issue but I'm running out of other explanations. Anyone else seen this? Is there a good alternative to PeekNamedPipe?

--Jon

[Dann Corbit]

I've been using the PeekNamedPipe function for many years to check for input from the chess GUI (Winboard, Shredder, etc.) during a search. This was used in Gnuchess, Beowulf and many other programs previously.

Lately though I have seen some cases running Windows XP x64 on a 4-core box where the engine is not "woken up" by input from Winboard.
It is pondering and I see debug output from the ponder search in the log, so the search is not stopped or hung. The sampling interval for input is reasonable. But the Winboard log shows data coming in and it is never read. This is a sporadic problem. Usually it's ok but maybe once a day on ICC I'm seeing this issue.

There are some reports of problems with PeekNamedPipe under Windows XP, in a multi-threaded environment, see for example:

http://msdn.microsoft.com/en-us/library ... S.85).aspx

http://www.duckware.com/tech/peeknamedpipe.html

But this doesn't seem exactly relevant (and it is reportedly fixed now).

I'm not clear this is a Windows issue but I'm running out of other explanations. Anyone else seen this? Is there a good alternative to PeekNamedPipe?

--Jon

I think that a separate I/O thread is a good model (or even a console read thread and a console write thread). It seems to me that this approach solves all the problems.

I guess that it is also much more efficient, since waiting on a read is not going to eat CPU cycles and polling is.

[trojanfoe]

I've been using the PeekNamedPipe function for many years to check for input from the chess GUI (Winboard, Shredder, etc.) during a search. This was used in Gnuchess, Beowulf and many other programs previously.

Lately though I have seen some cases running Windows XP x64 on a 4-core box where the engine is not "woken up" by input from Winboard.
It is pondering and I see debug output from the ponder search in the log, so the search is not stopped or hung. The sampling interval for input is reasonable. But the Winboard log shows data coming in and it is never read. This is a sporadic problem. Usually it's ok but maybe once a day on ICC I'm seeing this issue.

There are some reports of problems with PeekNamedPipe under Windows XP, in a multi-threaded environment, see for example:

http://msdn.microsoft.com/en-us/library ... S.85).aspx

http://www.duckware.com/tech/peeknamedpipe.html

But this doesn't seem exactly relevant (and it is reportedly fixed now).

I'm not clear this is a Windows issue but I'm running out of other explanations. Anyone else seen this? Is there a good alternative to PeekNamedPipe?

--Jon

I think that a separate I/O thread is a good model (or even a console read thread and a console write thread). It seems to me that this approach solves all the problems.

I guess that it is also much more efficient, since waiting on a read is not going to eat CPU cycles and polling is.

Agreed - a separate read thread, spending 99.9% of its time blocked in ReadFile, was the only way I could get reliable I/O with Windows Pipes.

[jdart]

Agreed - a separate read thread, spending 99.9% of its time blocked in ReadFile, was the only way I could get reliable I/O with Windows Pipes.

I've now implemented this and it seems to have fixed the problem, although more testing is needed. I'm still using polling on other platforms.

--Jon