On 6/11/24 02:43, Waldek Hebisch wrote:
On Sun, Jun 09, 2024 at 01:55:36PM +0800, Qian Yun wrote:
Any remaining issues and questions?
Can we move forward to include these patches?
Personally I would keep 'wait_for_client_read' just now.
Our processes can exit and at least in principle restart
and reconnect. So some way of handling reconnection is
needed. The code indeed looks like it does not work,
but keeping it probably is safer.
Our code already can handle client reconnect.
The server socket is put into "select" main loop and can
handle new connections.
This 'wait_for_client_read' happens at "read", it may even
happen on client side!
On the other hand, it's hard to imagine that a unix domain
socket connection get disconnected unexpectedly. In this
case, we should consider shutting down process, instead of
trying to recover from it.
Off topic a little on Internet connection: there's code
suggest we can use Internet connection instead of unix domain
socket connection. But I've find in many places the code
relies on unix domain socket specifically, such as EPIPE
and detection socket peer shutdown. So shall we cleanup
those Internet connection parts?
In longer term we should create diagram of expected interactions
between processes and verify that communication between
processes works as desired. But this is larger effort
and will take time. For now I prefer "most conservative"
solution. As I wrote in another mail, I would like to do
new release in June and would like to include the changes.
As a compromise, I can keep 'wait_for_client_read' in 'sread'
and only replace the problematic 'sread' calls.
- Qian
--
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/168b5f98-0452-4efb-85fe-cfc9443ff7a5%40gmail.com.
