Detecting 'stop search' key.

[Carey]

I'm helping somebody port an ancient chess program to modern systems. It's not written in C, so we are using a converter program along with a 'portability' support file to provide some additional functions.

We are using GNU C exclusively because it supports nested functions.

It is a plain command line program, with no GUI.


What I need is some way to portabilty detect when a user presses a 'stop searching' key. It has to work under Windows, Mac and Linux.

All I need to do is set a flag if the user presses some sort of 'break' or 'escape' key. I don't have to jump to any special routine or such.


In the old days, I'd just use SIGINT, but that doesn't work under MingW & Windows. (At least it didn't the last time I tried it a few years ago. I'm too lazy to check again since I doubt it'll work now.)

I'm not sure of the best way to do this portably.

Any ideas?

[wgarvin]

I don't know of any portable way to do that. I suggest you do one implementation for Windows, and a different one for Unix-like systems. Maybe SIGINT will do what you want on the Unix-like systems.

For Windows, I suggest using a separate thread to read input into a buffer, and then having your engine thread actually get its input from that buffer (with critical sections or whatever, for thread-safety). That way, you can tell if the buffer is empty or not.

Another possibility might be to cache up to 1 character of input, and read a max of 1 character from the engine thread as a way to "peek" for input.

Maybe some engine authors who've dealt with this, can suggest a better way?

[Roman Hartmann]

Hi,
have a look at the source code of any (up to date) chess engine and look for a function called bioskey() to get an idea.

Roman

[Carey]

Hi,
have a look at the source code of any (up to date) chess engine and look for a function called bioskey() to get an idea.

Roman

Thanks, but...

First, most other programs are copyrighted or worse, infected with the GPL. Considering this isn't my program, it's definetly not a good idea to take that code and attach it to somebody elses.

Second, of the routines I have seen over the years, the ones I can remember are only concerned with detecting whether or not any keyboard input is ready. This is needed for winboard support.

However, that's not what I'm actually looking for.

I need to detect a specific key (like break, escape, etc.) without effecting the existing code and how it does I/O.

In the old days, you could trap for <ctrl-c> or something, but those days are long over and it's not portably anyway.

Thanks though.

[Carey]

I don't know of any portable way to do that. I suggest you do one implementation for Windows, and a different one for Unix-like systems. Maybe SIGINT will do what you want on the Unix-like systems.

If I remember my Unix days right, SIGINT would work. But not under windows. And since Windows is 90% of the systems, that's a problem.

For Windows, I suggest using a separate thread to read input into a buffer, and then having your engine thread actually get its input from that buffer (with critical sections or whatever, for thread-safety). That way, you can tell if the buffer is empty or not.

A couple problems with that.

First, dealing with threads can be a bit of a pain especially when talking about portability.

Second, intercepting the I/O itself isn't easy to do. Because of the translated nature of the program, the I/O is having to go through a 3rd party package and intercepting it there might be possible, but certainly not convenient.

Another possibility might be to cache up to 1 character of input, and read a max of 1 character from the engine thread as a way to "peek" for input.

Maybe some engine authors who've dealt with this, can suggest a better way?

I hope so.

I miss the old days of DOS where you could just intercept <ctrl-C>, or the days of Unix where you could do SIGINIT.

Those days are over, though. And trying to deal with Windows, Linux and a Mac is going to be annoying.

(I have to do windows for myself and 90% of everybody else. I have to do Mac because that's what the chess program's author is using. I have to do Linux for the author of the other part of the support package and anybody else interested in this old program.)

[Roman Hartmann]

Seems you got me wrong. I wasn't suggesting that you copy and paste any source code but rather that you have a look what kind of routines are used instead of kbhit() these days. bioskey() is usually just the container for some system calls.

Roman

[Carey]

Seems you got me wrong. I wasn't suggesting that you copy and paste any source code but rather that you have a look what kind of routines are used instead of kbhit() these days. bioskey() is usually just the container for some system calls.

Roman

Sorry about that then. My mistake.

The problem with doing bioskey or kbhit is that you have to explicitly check them on a regular basis.

Then you have to check and see if it's really the abort key or some other key press. That can make a difference if you are doing batch input or the user is just typing ahead.

The original program expects to have the abort flag set at any time without it effecting the input status.

I don't want to change the behavior of the old program too much.

Explicitly checking for input would require either doing threads (not trivial, not portable) or adding a few extra calls and trying to extract a specific key press out of the input stream.


The easiest would indeed be do something like kbhit() and just assume its time to abort the search or exit the pondering. But I'm not sure that's the best way with this antique program.

It's a 30+ year old program that was written for mainframes and teletypes and it does things the old style, including an explicit 'break' or 'attention' key.


I'll email the author and get his opinon on making some extra changes to the source.

[trojanfoe]

I would always prefer to use multiple threads but if you just want to use one thread you can set-up a 'Console Control Handler' under MS Windows and a signal handler under Linux/UNIX systems. This is an expensive and unexpressive method of dealing with input but again the best solution is multiple threads - it's actually not hard to write threading functions for Windows/Linux that would be different in only a couple of ways.

[Michel]

First, most other programs are copyrighted or worse, infected with the GPL.

So you prefer a closed source program to one which is freely to use and modify by anyone?

You can freely take ideas from a GPLed program. You cannot directly copy code from a GPLed program to a closed source program. That is only fair I think.

[Carey]

First, most other programs are copyrighted or worse, infected with the GPL.

So you prefer a closed source program to one which is freely to use and modify by anyone?

You can freely take ideas from a GPLed program. You cannot directly copy code from a GPLed program to a closed source program. That is only fair I think.

I didn't say I prefered closed source. I didn't mention it at all, actually.

I said exactly what you quoted above.

That you can't cut code from a copyrighted program and paste it into yours. (Well, you can, actually, if its copyrighted freeware and says you can use it provided credit is given, or some such kind of license. But that's not the kind I was refering to in that specific instance.)

And I said I disliked the GPL.

I didn't say anything bad about open source. Whether it's public domain, copyrighted freeware, MIT, BSD, etc. licensed. (In fact, I've written a few open source programs over the years. Probably nothing you'd care about, but it took me effort to write and I did make it open source.)

I said "... or worse, infected with the GPL".

I doubt the moderators want this conversation to get into a discussion about the GPL itself, or as a GPL vs. other open source license discussion, so let's just say that I obviously dislike the GPL in particular.

Not everybody is in love with the GPL, which is why other, non-public domain, open source licenses exist.