Eschecs FreeBASIC (UCI chess GUI)

[fxm]

Is 'GetSysEvents()' executed from the other thread 'ProcedureThread()' than from the main thread ?

[Roland Chastain]

Is 'GetSysEvents()' executed from the other thread 'ProcedureThread()' than from the main thread ?

It's only called by sGui itself, in xSleep procedure:

Code: Select all

' sgui_eventhandle.bas
sub EventHandle.xSleep (eventmode as integer,XButton as integer=1)
  dim as integer eventoccurred=0
  do
    ' ...
    if eventmode>-1 then sleep 1, 1

    eventoccurred=GetSysEvents(XButton)

[fxm]

xsleep() is called from the main code loop do : event->xSleep(1) ..... end if : loop until event->EXITEVENT).

Now my precise question is:
But is xsleep() also called indirectly form the ProcedureThread() execution ?

[Roland Chastain]

xsleep() is called from the main code loop do : event->xSleep(1) ..... end if : loop until event->EXITEVENT).

Now my precise question is:
But is xsleep() also called indirectly from the ProcedureThread() execution ?

No, xSleep() is called nowhere else than in the main loop.

ProcedureThread() calls OnOutput(), which calls other functions.

[fxm]

Could you try at first the following:

- You have already a [MutexLock...MutexUnlock] block around '.procedure(engineOutput)'.
Extend it to the all 'ProcedureThread()' [Do...Loop] body (except 'sleep(50, 1)'):

Code: Select all

'' In eschecs.bas
.....
sub ProcedureThread(byval param as any ptr)
  DebugLn("->")
  dim engineOutput as string
  with *cast(TListener ptr, param)
    do
      mutexlock(.sync)  '' <==
      engineOutput = ReadEngineOutput
      if len(engineOutput) > 0 then
        .procedure(engineOutput)
      end if
      mutexunlock(.sync)  '' <==
      sleep(50, 1)
    loop until .quit
  end with
  DebugLn("<-")
end sub
.....

- And add a [MutexLock...MutexUnlock] block (with same mutex pointer) around 'KEY=Inkey'' in ''GetSysEvents()':

Code: Select all

'' In sgui_systemevents.bas
.....
.....
function GetSysEvents(XButton as integer) as integer  
  .....
  mutexlock(listener->sync)  '' <==
  KEY=inkey
  mutexunlock(listener->sync)  '' <==
  
  ScreenEventExists=1
  .....
end function
.....

- Then test if that works !

[Roland Chastain]

Thank you fxm. I am afraid to shout "victory" too soon, but it seems to work. I uploaded the code so that the volunteers can test: eschecs.zip

I could also try to restore the screenlocking in sGUI, using the same trick?

[fxm]

Before, it would be interesting to determine if the [MutexLock...MutexUnlock] block is mandatory for only 'engineOutput = ReadEngineOutput', or for only '.procedure(engineOutput)', or for the both as now is.

[fxm]

I could also try to restore the screenlocking in sGUI, using the same trick?

Yes for each screenlocking block:

Code: Select all

  mutexlock(listener->sync)  '' <==
  screenlock
    .....
  screenunlock
  mutexunlock(listener->sync)  '' <==

[Roland Chastain]

Before, it would be interesting to determine if the [MutexLock...MutexUnlock] block is mandatory for only 'engineOutput = ReadEngineOutput', or for only '.procedure(engineOutput)', or for the both as now is.

I tried to remove it for both. The application still seems to work. It looks like the problem was with the inkey. But I cannot be absolutely certain, because I experienced that the bug could stay hidden for a long time (several games).

[fxm]

I tried to remove it for both. The application still seems to work. It looks like the problem was with the inkey. But I cannot be absolutely certain, because I experienced that the bug could stay hidden for a long time (several games).

Indeed !
If only 'KEY = Inkey' (in 'GetSysEvents()' is protected by a mutex block in all the code, this is useless because 'GetSysEvents()' is only called from the main loop (from the main thread only), therefore it cannot be in conflict with itself (conflict is only if it is also called from another thread).
Therefore, either the two mutex blockings are both useful, or none is useful.

[Roland Chastain]

I tried to remove it for both. The application still seems to work. It looks like the problem was with the inkey. But I cannot be absolutely certain, because I experienced that the bug could stay hidden for a long time (several games).

Indeed !
If only 'KEY = Inkey' (in 'GetSysEvents()' is protected by a mutex block in all the code, it is useless because 'GetSysEvents()' is only called from the main loop (from the main thread only), therefore it cannot be in conflict with itself (conflict is only if it is also called from another thread).
Therefore, either the two mutex blockings are both useful, or none is useful.

I see.

Another problem. I restored the screenlocking in sGUI with mutexlock/mutexunlock. But I didn't pay attention to the fact that my "listener" thread is not yet created when application starts. Currently, I am creating the thread only if the chess engine process was successfully started. I did it that way to avoid violation access in ReadEngineOutput function when the process hasn't been started.

Which strategy would you suggest? First I had the idea to add a supplementary field in the TListener type, for example pause as boolean, and do something like this:

Code: Select all

if not .pause then engineOutput = ReadEngineOutput

What do you think of that idea?

[fxm]

A safe way (both for screen locking and Inkey) would be:

Code: Select all

  If listener <> 0 Then mutexlock(listener->sync)  '' <==
  .....
  If listener <> 0 Then mutexunlock(listener->sync)  '' <==

[Roland Chastain]

Done, thank you for your help. Files updated: eschecs.zip

You can also get the files here:
https://www.freebasic-portal.de/downloa ... s-210.html

Testers are welcome!

I fixed the new pictures (coming from the Warlord chess program). Some pieces were lower than other.



You can use the new pieces set by starting the application with the following parameter: --squareWidth=48

You can also set the time allowed for computer move. The default value is 1000 (one second). To have more chance to beat Fruit, you can use for example: --moveTime=500

[fxm]

Fingers crossed that this does not crash anymore !

[Roland Chastain]

Fingers crossed that this does not crash anymore !

Yes, let's hope. :)

By the way, there is a bug in the chess library.



In that position the castling on the left should be allowed.