"Fossies" - the Fresh Open Source Software Archive

Member "cadabra2-2.2.6/client_server/TODO" (9 Apr 2019, 1827 Bytes) of package /linux/privat/cadabra2-2.2.6.tar.gz:


As a special service "Fossies" has tried to format the requested text file into HTML format (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file. See also the last Fossies "Diffs" side-by-side code changes report for "TODO": 2.1.7_vs_2.2.0.

    1 
    2 Can it ever happen that e.g. the user selects a cell, clicks delete, but before
    3 the Action can be 'perform'ed, the client has already removed it?
    4 
    5 
    6 The problem is that the user interface can fire off a Delete action and then happily
    7 request other things to that cell before the delete has happened. Or can it? With
    8 calling perform, you always run on the gui thread. This thread should just execute
    9 all actions immediately, all the way down to the gui update.
   10 
   11 LATER: It's worse: you can set a cell to execute, then delete it while the cell
   12 is still running. When the return data comes in and the computethread wants to
   13 add the child output cell, the original one has gone and the pointer is stale => segfault.
   14 You can't avoid this with doing actions in sync. You can prevent it by requiring that
   15 a delete can only happen on cells which are not executing.
   16 
   17 
   18  -> maybe the best is to make 'perform' execute all the way through, and make
   19     a separate member, only accessible to the client, which does actions by
   20     waking.
   21 
   22     perform_sync();
   23 
   24 
   25     perform_async();
   26 
   27  -> No, let the GUI thread do all updates. The client can only request updates, the
   28     gui thread executes them. Then it becomes easy to force the gui to first run the
   29     outstanding requests before doing its own.
   30 
   31     HOWEVER, in this case we have to worry about how the client stores ActionBase.
   32     The GUIThread holds the action stack, but the NetThread can lock it and write
   33     into it.
   34 
   35 
   36 Make sure to keep the GUIBase and Client classes separating the thread actions.
   37 Some stuff should probably move out from Client -> GUIBase. Also: rename to
   38 GUIThread and NetThread.  Or maybe add SharedData to separate it out even cleaner.
   39 
   40 
   41 * We are passing around all data in the form of shared ptrs, but that ignores
   42   the tree structure. Perhaps change this?