On 4/19/24 20:41, Waldek Hebisch wrote:
Long ago I looked at communication protocol between various
processes that we use and my conclusion was that it is
inherently racy: there are parallel chanels of communication
and both ends assume that data comes in right order. I added
a little piece of code to detect lost race, that mitigates
worst things. Machines now are faster than in the past,
so lost races probably are quite rare given 1s delay.
It is quite possible that original authors after realizing
that there are races put delays in places that are not necessary
(and wrogly placed delay could even make races worse).
To explain more: most of C code uses sockets and this alone should
be OK. However, data from FRICASsys sends textual output on
standard output, which is captured by 'sman'. But "event indicators"
are sent via sockets, so we depend on data on FRICASsys standard
output and data coming via sockets to arrive in order in which
it was sent.
In this particular case, it is not socket, but pipe.
The only reason to put a "sleep" here,
I presume it is a workaround for a bug in viewAlone:
See the "printf" I removed bellow: it writes to stdout instead of
stderr, causing the parent process function "readViewport" to return
early and make parent process exits, and the data passed to child
process via pipe is lost.
IIRC 'viewAlone' is started from HyperDoc when you click on a image.
Normal graphics uses 'view2D' and 'view3D' via 'viewman'.
Anyway, I think it would be reasonably safe to use smaller delay,
say 50 or 100 milliseconds (I use such delay during startup).
Quite possible that we can elliminate the delays, but that IMO
would require deeper analysis and more testing. As I wrote we
have several channels of communication and code assumes certain
ordering contraints. Without identifying contraints (and some
could be far from obvious) and analysing them it is hard to say
more than "there are races".
This case is rather straight forward I think, viewman/viewAlone
forks and passes data to child process view2D/view3D via pipe,
then child process writes a value after receiving all data,
then viewAlone exits while viewman sends it via sock to fricas
and continues to run.
I can accept the 100ms sleep as well. But could you give this
another review based on the new information I provided?
- Qian
BTW: My inital motivation for work on streams was to pass all
FRICASsys (actually it was called AXIOMsys at that time) output
to sockets, which would allow messages with confirmation.
--
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 fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/83664668-d3a4-40b1-b9d7-ef5d26fdc696%40gmail.com.
