New interesting, but still experimental feature in GalisWBTM

[galis]

All Winboarders has expirienced buggy engines which hangs in RAM memory after winboard exits. But, from now GalisWBTM has cure for such behavior.
If someone has interest for testing new experimental GalisWBTM v1.1.1, you can send me mail with subject: "Experimental feature in GalisWBTM".
Also this version is bugfix (several reported bugs has corrected).

Important: I dont know if this version can run under 64-bit Windows OS (if somebody uses such OS, I'm interesting for feedback information).

Best regards

Galis

[Fabien Letouzey]

Hi,

Can you explain what your new feature does? I suspect it kills the child process after a timeout but the exact conditions are interesting for me. More importantly, is the feature optional?

In the case additional software is used (such as adapter), killing the child process is in fact worse than not doing it (because it is not the engine). So we have to be careful with this.

Thanks,

Fabien.

[galis]

Hi Fabien
As you know many UCI engines which using your excelent tool for working under Winboard, hangs in RAM after winboard exits. GalisWBTM collects all processes created from winboard (including your polyglot.exe) when winboard session starts, and when session ends, he gives 2 sec for engines to shutdown itself regularly. And then checks RAM for hanging engines and simply terminate these processes. Well, other way is to use windows task manager and do it manualy, isn't it? But if you lunch overnight tournament you can not do this, because you are sleep or having good time with beautifull girls ). And hanging engines stealing processor time from other engines, strongness of these engines rapidly downs - we haven't correct estimation for engine strongness.
Of course that feature is optional (I don't know if you are familiar with my tournament manager, but many options you can set on very easy way). And you have right, teoreticaly terminating processes could be dangerous. Because of that I said it's experimental feature. But, after 3 days of my heavily testing period I have expirienced zero problems.
I hope my answer was useful to you.
Best regards
Galis

P.S.
By the way, I have expirienced strange befavior on your polyglot 1.0, some engines starts more than one instance of polyglot. Why is that?

[Fabien Letouzey]

Hi,

Yes very useful answer. If you collect all processes (including subprocesses), all is fine and the engines will indeed be closed (although data files might become corrupt).

My number-one problem is why does WinBoard quit in the first place (especially without even a timeout it seems)??? Everything would be fine if it waited for the engine to close the connection. As far as I know, this is the behaviour of XBoard and therefore I cannot detect any problem on my Linux system.

The two PolyGlot processes are an artefact of the CygWin DLL. In Unix processes are (virtually) duplicated before they are "overwritten" by an executable. Since Windows is not compatible with this the DLL probably has to create an additional process whose only purpose is to wait for termination of another one. So no worries, it eats no CPU or memory (allocation is meaningless in decent OSes using virtual memory).

Fabien.