On 5/5/24 16:16, Waldek Hebisch wrote:
Testing recent patch by Qian I got 'view3D' which showed empty
window and used 100% of a core. A little investigation using 'gdb'
shows that this 'view3D' was trying to exit. This was triggered from
a signal handler: 'view3D' received a signal (SIGTERM I think) and
'goodbye' in 'stuff3d.c' was the hander. However, signal arrived
during X11 call, namely 'view3D' was calling 'XGetWindowAttributes'
from 'libX11'. IIUC this is incorrect: one is not allowed to perform
X11 call when another call is in progress.
So, IIUC what you are saying then X11 is to blame.
With Qian's patch one file, for example, ug11.input is processed under
xvfb. This is basically one X11 session running. If we could split the
commands to several xvfb+fricas calls, then they cannot possibly
interact with each other since these would be different X11 sessions.
Is this a correct picture?
Well, I am not saying, that it is actually possible to split the \psXtc
stuff into separate parts, since some might depend on the execution of
previous \psXtc environments. But I guess such a splitting would also
avoid races. Am I wrong?
Recent changes just give me extra incentive to run 'make
book.pdf'...
I am against inclusionn of Qians patch if it forces me only to hope that
the book will be compiled correctly.
Waldek, what you are saying does not sound like these races come from
"make -jN ..." with N>1, since each file is processed under a separete
xvfb. These races should also happen with -j1, right?
Ralf
--
You received this message because you are subscribed to the Google Groups "FriCAS -
computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/35321961-0cd0-43e6-8854-af5b616a2979%40hemmecke.org.
