Eschecs FreeBASIC (UCI chess GUI)
-
- Posts: 1007
- Joined: Nov 24, 2011 19:49
- Location: France
- Contact:
Eschecs 1.2.3
Version 1.2.3. Chessboard coordinates. Creation of a INI file for settings.
Download (source code only)
Download (source code only)
Re: Eschecs 1.2.1 (UCI chess GUI)
Is there any disk file opening with reading or writing during the main loop (main thread) but executed from the other thread ?Roland Chastain wrote:Yes, let's hope. :)fxm wrote:Fingers crossed that this does not crash anymore !
'LoadFileAsString()' ?
-
- Posts: 1007
- Joined: Nov 24, 2011 19:49
- Location: France
- Contact:
Re: Eschecs 1.2.1 (UCI chess GUI)
That function is called at application start, to load JSON files. It is called from the main thread. In the latest version (1.2.3), there is an INI file, also read from the main thread.fxm wrote:Is there any disk file opening with reading or writing during the main loop (main thread) but executed from the other thread ?
'LoadFileAsString()' ?
Re: Eschecs 1.2.1 (UCI chess GUI)
I am looking for any input or output operation that would be executed from the other thread during the main loop of the main thread.
-
- Posts: 1007
- Joined: Nov 24, 2011 19:49
- Location: France
- Contact:
Re: Eschecs 1.2.1 (UCI chess GUI)
The procedure OnOutput writes to eschecs.log. And also the dependent procedures: OnUciOk, OnBestMove...
Re: Eschecs 1.2.1 (UCI chess GUI)
Thus, it would appear that the mutex locking block in 'ProcedureThread()' could be reduced to:
as previously.
Code: Select all
sub ProcedureThread(byval param as any ptr)
DebugLn("->")
dim engineOutput as string
with *cast(TListener ptr, param)
do
if .doReadOutput then
engineOutput = ReadEngineOutput
else
engineOutput = ""
end if
if engineOutput <> "" then
mutexlock(.sync)
.procedure(engineOutput)
mutexunlock(.sync)
end if
sleep(50, 1)
loop until .quit
end with
DebugLn("<-")
end sub
-
- Posts: 1007
- Joined: Nov 24, 2011 19:49
- Location: France
- Contact:
Re: Eschecs 1.2.1 (UCI chess GUI)
OK, thank you fxm.
By the way, maybe we could find better names. The names ProcedureThread and listener.procedure create a confusion.
By the way, maybe we could find better names. The names ProcedureThread and listener.procedure create a confusion.
Re: Eschecs 1.2.1 (UCI chess GUI)
Why not 'listener.callback' ?
-
- Posts: 1007
- Joined: Nov 24, 2011 19:49
- Location: France
- Contact:
Re: Eschecs 1.2.1 (UCI chess GUI)
Yes. Here is the final (?) version, with other minor modifications.fxm wrote:Why not 'listener.callback' ?
Code: Select all
sub ThreadProcedure(byval aParam as any ptr)
DebugLn("->")
dim s as string
with *cast(TListener ptr, aParam)
do
if .doRead then
s = ReadEngineOutput
if s <> "" then
mutexlock(.sync)
.callback(s)
mutexunlock(.sync)
s = ""
end if
end if
sleep(50, 1)
loop until .quit
end with
DebugLn("<-")
end sub
Re: Eschecs 1.2.1 (UCI chess GUI)
Why here is a conflict (inducing crash without mutex) between 'INKEY' executed from a thread and 'PRINT #' executed from another thread ?
But I can not seem to highlight the crash with simple code (Windows 10) !
- The conflict can not be between 'INKEY' and 'PRINT #' (to disk) because this impacts two different devices.
- Therefore I wondered for a long time why so there was conflict between 'INKEY' and 'PRINT #' (to console), because they are using two different streams.
- But, by re-reading the 'Open Cons' documentation page, I think maybe I have a clue, thanks to the following warning paragraph:
Warning: Presently, Open Cons does not work as described above. Without any file mode specifier, a runtime error 1 (illegal function call) occurs. With the Input file mode specifier, the only input mode is well supported. But with the Output file mode specifier, input and output modes are simultaneously supported.
But I can not seem to highlight the crash with simple code (Windows 10) !
-
- Posts: 1007
- Joined: Nov 24, 2011 19:49
- Location: France
- Contact:
Re: Eschecs 1.2.1 (UCI chess GUI)
Thank you fxm for your investigations. Yes, it would be good to understand exactly the problem. Unfortunately I can't help you help much, because all that is still not very clear for me. I intend to retouch soon a project which has more or less the same configuration. I hope it will be the occasion to see clear in that affair.
I uploaded the latest version of my code, with a minor correction in the Windows version (about pointer size when compiling to 64-bit). Includes executables for Linux and Windows. Tests and comments still welcome.
[link deleted]
P.-S. I still would like to understand why the application uses much processor, even when it does apparently nothing. I tried to increase the sleep value in sGUI xSleep: it makes the reaction to mouse move slower, but the processor usage stays the same.
I uploaded the latest version of my code, with a minor correction in the Windows version (about pointer size when compiling to 64-bit). Includes executables for Linux and Windows. Tests and comments still welcome.
[link deleted]
P.-S. I still would like to understand why the application uses much processor, even when it does apparently nothing. I tried to increase the sleep value in sGUI xSleep: it makes the reaction to mouse move slower, but the processor usage stays the same.
-
- Posts: 1007
- Joined: Nov 24, 2011 19:49
- Location: France
- Contact:
Re: Eschecs FreeBASIC (UCI chess GUI)
Hello everybody!
I applied the modifications suggested by neil here (thanks to him), and uploaded the project to a git repository:
https://codeberg.org/rchastain/eschecs-freebasic
Compilation successfully tested with fbc 1.10.1 under Linux.
I applied the modifications suggested by neil here (thanks to him), and uploaded the project to a git repository:
https://codeberg.org/rchastain/eschecs-freebasic
Compilation successfully tested with fbc 1.10.1 under Linux.