On Thu, Dec 26, 2024 at 06:14:15PM +0800, Qian Yun wrote:
> On 12/25/24 10:07 PM, Waldek Hebisch wrote:
> >
> > However, it looks to me that you eliminated one (significant) problem,
> > but there is still parallel signalling between processes, which
> > may lead to races. That is we should change communication protocal
> > between our processes to be essentially message based.
> >
>
> What's your opinion on my thread titled "An idea to greatly
> simplify socket communication protocol / sman process tree"?
> (Namely to move the main IO loop from "session" to "FRICASsys",
> thus greatly reduce the number of processes and parallel signalling.)
I am affraid of potential problems:
- FRICASsys is compute-intensive, computations may block
communication leading to trouble (this is problematic now,
but having more things in FRICASsys may make problem worse).
- duplicating file decriptors without knowledge of Lisp may
lead to troubles. In particular, in the past we had trouble
which was due to buffering between Lisp I/O and OS I/O.
To explain a bit more: I would prefer a protocol where at start
of message we have size. Size allows reliably finding boundaries
between messages. But this looks impossible with current Lisp
I/O.
Let me mention anouther thing. For some period we had trouble
with Control-C handling in sbcl. It turned out that sbcl
developers changed internals and decided to use SIGPIPE for
their Control-C handling. But our C routines intercepted
SIGPIPE, which broke "new" sbcl Control-C handling (I write
"new" in the quotes, as this is old story now).
Note that arguably Unix signals are for applications to use
and I did not find any info about reserving SIGPIPE in sbcl
documentation. File descriptors for Lisp streams IMO are
part of Lisp implementation, they may break our use at any
time.
--
Waldek Hebisch
--
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 visit
https://groups.google.com/d/msgid/fricas-devel/Z26QNjFuKedd6lmU%40fricas.org.
