"unknow editor id" race condition due to UI replacement before an edit event has been handled
The following program has an editor on a shared value. The shared value is being reset in the background. Because the list editor reassigns editor IDs when the value is updated externally (see also #317), there exists a race condition:
- Background task modifies value
- User modifies value
- Editor is replaced based on 1
- (User receives new editor)
- Edit event from 2 cannot be handled because it is based on old editor IDs
Due to #317 the problem is easy to reproduce in the list editor, but it should exist in other editors that do a replace as well.
To solve the problem I considered invalidating all edit events in the queue when there is a refresh, but the race condition would still exist if the edit event has not yet entered the queue in step 3.
Perhaps we should just write something to stderr when there is an unknown editor ID, but not throw an exception?
@baslijns I can implement that myself, but your thoughts would be very helpful here.
A more sophisticated solution might be to keep track of old editor IDs and still throw an exception when an editor ID is used that was never valid, or became invalid a long time ago. But the implementation would be vastly more complicated and I don't see many benefits for now.
FWIW, similar race conditions probably existed before the move to editor IDs, when the data path became invalid due to changes to the share. However examples like below only cause the race conditions in the editor ID setup because the data paths would have been unchanged.
import iTasks import iTasks.Extensions.DateTime Start w = doTasks task w where task = withShared  \s -> forever (set  s >-| waitForTimer False 1) -&&- updateSharedInformation  s
In this screencast I hold the left mouse button to update the value. When the value is reset you need to release and click again. It takes a couple of times for the race condition to appear: