Any WinBoard bugs I missed?

[Robert Pope]

As long as there are no files involved fine. Don't like working with files or databases. But programming is not fun.

You may have made a poor choice of hobby, then.

[jdart]

I notice xboard seems to proliferate "aplay" processes, for example:

aplay -q /usr/local/share/games/xboard/sounds/gong.wav

I do sometimes kill the parent process (xboard) and it seems these other processes don't die.

--Jon

[bob]

I notice xboard seems to proliferate "aplay" processes, for example:

aplay -q /usr/local/share/games/xboard/sounds/gong.wav

I do sometimes kill the parent process (xboard) and it seems these other processes don't die.

--Jon

This requires a signal handler to catch SIGCHLD signals (the signal delivered when a child process terminates. In the signal handler you have to do a waitpid(-1, &status, WNOHANG) repeatedly until it returns a value <= 0 to indicate you have cleaned up all the zombie processes that are waiting around to report their termination status back to the parent (xboard).

[hgm]

I notice xboard seems to proliferate "aplay" processes, for example:

aplay -q /usr/local/share/games/xboard/sounds/gong.wav

I do sometimes kill the parent process (xboard) and it seems these other processes don't die.

That should count as a bug in your 'aplay'. As far as XBoard is concerned, aplay is 'fire and forget'. No communication channel is set up between XBoard and the sound app, it just uses system("aplay -q ..."); and goes on. aplay is supposed to terminate once it is done playing the indicated sound. The .wav files are all of finite duration, so there is no way an aplay process should be able to stay alive.

[sje]

Audio output assumptions

I haven't used xboard in a while because I've been off the chess servers for a couple of years. So my comments could be out of date.

I recall having some difficulty with the aplay business because it was not a standard application on either my Linux boxes or on my Mac OS/X boxes. I believe that voice synthesis output as an option is a good idea (I use it with Symbolic), but it's also important to not to make too many assumptions about an end user's environment.

For Mac OS/X, xboard could use the say program which turns text into speech. For Linux, the similar program spd-say could be employed, but this might require a bit more work on the part of the end user to correctly configure the Linux speech dispatcher service.

Then there's the related problem of choosing a portable way of playing arbitrary sound files.

Maybe xboard could have a pre-run configuration checker to probe the end user environment for whatever support applications might be needed. If xboard can't be sure that a particular application is present, then it shouldn't try to call it during normal operation.

[hgm]

The sound player can be set in the Options->Sounds dialog.

As for assumptions about the environment, ./configure is supposed to take care of that. This is not a part of XBoard I do myself, but I will ask Arun if it is possible to have configure check which the default sound player is, and use that as a compiled-in default.

For people using binary packages, the package maintainer should take care of this by compiling with the standard player for the distro the package belongs to, and list that amongst the package dependencies. Problem here is that they are often quite reluctant to consider something a dependency. In principle XBoard is usable without sounds, so they probably would make it a 'recommends' at best. I am not sure that would trigger an automatic install.

Of course the Mac offers a pretty non-standard environment, as far as Linux goes. But for the Mac there now is the native OS X XBoard app, and I guess the solution would be to simply distribute that configured for using the standard OS X sound player.

As for text-to-speech: yes, it would be nice to have that, and a ot of back-end code already exists for it in the WinBoard for JAWS version. There was a GSOC project by someone that wanted to make an accessible version of XBoard for the visually impaired, but I don't know if anything has come of it.

[jdart]

I don't know why it wouldn't terminate but it seems sometimes it doesn't.

I notice aplay apparently has a -d flag to set the duration, maybe that would help workaround this.

Or xboard could kill it.

--Jon

[JoshPettus]

As far as OSX is concerned there is a commandline program that already comes with the OS called "afplay" this uses any format acceptable by quicktime. I have had no issues with it staying open after playing.

I already made this the default sound program in xboard.app

As far as OSX with blind accessibility, there is a built in function for this called VoiceOver, but it's only for Cocoa applications. I don't think there is anyway around this. It does read off the menu however. but not the dialog boxes.

[bob]

I notice xboard seems to proliferate "aplay" processes, for example:

aplay -q /usr/local/share/games/xboard/sounds/gong.wav

I do sometimes kill the parent process (xboard) and it seems these other processes don't die.

That should count as a bug in your 'aplay'. As far as XBoard is concerned, aplay is 'fire and forget'. No communication channel is set up between XBoard and the sound app, it just uses system("aplay -q ..."); and goes on. aplay is supposed to terminate once it is done playing the indicated sound. The .wav files are all of finite duration, so there is no way an aplay process should be able to stay alive.

Do you do a fork()/system() to run it? If so any child process goes into the "defunct" or "zombie" state when it terminates, until the parent executes something like a waited() to clean it up. Here's the basics of what you need to do:

(1) signal handler to catch SIGCHLD:

void SignalInterrupt(int sigtype) {
signal(SIGCHLD,SignalInterrupt);
printf("caught a signal <%d>\n",sigtype);
while (1) {
int status,r;
r=waitpid(-1,&status,WNOHANG);
if (r <= 0) return;
printf("exit status=%d %x\n",WEXITSTATUS(status), status);
}
}

Note that the printf's should be removed, they are there just to test.

(2) In the initialization for xboard, you need this:

signal(SIGCHLD,SignalInterrupt);

That will solve this. When you do a fork() and the process terminates, it becomes a zombie/defunct process. It doesn't take much memory, but it DOES take a process table entry. As you continue to fork() things, you can end up being up to your armpits in zombie processes and you can reach a point where no more processes can be forked. This is a common issue in a web server program that accepts a connection and then forks a process to handle it. The above will solve it completely...

[bob]

I don't know why it wouldn't terminate but it seems sometimes it doesn't.

I notice aplay apparently has a -d flag to set the duration, maybe that would help workaround this.

Or xboard could kill it.

--Jon

I don't think they are actually running. They are almost certainly in the "zombie/defunct" state (term depends on operating system, recent Linux kernels use <defunct>.