How state updates to existing instances/sessions are generally done?

Question

This is a very broad question, but maybe someone has a worthwhile response.

There is a general synchronization issue that often has to be solved, but always seems to be difficult. Here's an example:

I was working on a remote system and had an ssh-connection and a remote desktop open at the same time for some reason. I happened to create a file on the desktop in shell, and of course it also appeared on the remote desktop view.

For this to happen one of two things must take place:

1) the desktop session must be constantly polling the filesystem for changes. Costly, ugly, and of course unlikely.

2) The system knows that this change made by the ssh-session requires action on the remote desktop side, and updates the view. This is neat and elegant in a sense, but maintaining an accurate capability to decide when any action performed by any process in the system should cause this update is horrendously complex.

In this case the culprit is the linux kernel (or Desktop environment?) and I presume what it does is the option 2). It's also very common to encounter small bugs and issues that are clearly the result of this kind of issue not being taken care of.

This kind of a problem where any of multiple changes to a common resource can have an effect on other instances, but determining when is very tedious pops up in many places. Is there a general approach to this? Do we form separate trackers that know how the instance is sensitive to changes and that object can be interrogated? Does every change to the resource (filesystem in this case) include a stage of making sure this kind of stuff takes place? If so, that too must compound to be a massive ordeal. Does someone happen to know how linux handles this specific example case?

Answer 1

This is the curse of not having configurable physics.

Cause must happen before effect, but how closely these things appear, or even when they appear depends entirely upon where you are, your distance from the activity, and how time is passing for you.

And because we are talking about abstract process and logic (which is a very messy topology, not something as clean cut as space-time) it is hard to get a reasonable grasp on what distance and time even are.

Polling

Polling is certainly an option. While not necessarily the quickest option it is possible that any message about a state change simply has not reached your program yet. It may be that you can more quickly access the updated value, than be informed of the event that caused the update. You might not even be informed...

Events

Events are another solution. Intuitively when the state changes, the event should be sent out. If you are listening for it, then you can receive it and react.

The problem is that you cannot hear something before you register a listener for it, which means you have no idea about the state of the system now, unless registration also passes along some sort of state of the system event, which could be huge....

The other problems are:

• Perhaps a listener before you cancels the event so it is never received,
• perhaps the event takes such a long time to arrive it is marked as old and discarded,
• perhaps so many events are happening that the listener starts dropping them,
• perhaps the events arrive out of order mixing up what the systems real state is,
• perhaps the sender never sends the event but changed the state anyway...

Transaction Logs

Also sometimes called Event Logs, Event Streams, State Logs, Audit Trails, Block Chain, Raft Logs, etc...

These solutions require state changes to be recorded in a log first.

• At some point the values recorded in the log are acknowledged as being the "new" state.
• If a record proposes a state change that is illegal, its not acknowledged as correct, and is ignored.
• Because the log is serial there is a definitive order to the change in state.
• If the message never arrives that is fine, poll the log and resume reading from the last event previously processed, even if the process stops listening for a long time.
• If events arrive late, are dropped, or arrive out of order all is well poll the log for the missing events.
• The state of the system can be rebuilt to a specific point in time, even an historic point.
• When two processes wish to discuss state everyone can agree on a time and discuss the state in a synchronised way.

The down side is that the authority of state, moves from the logical models (which are now just views) into the log entries.