We have a goal where io-thread may receive from client-window a resetSession request. If this occurs, we should end our ISession and re-create it (and everything should 'just-work'), and keep a persistent io-thread to manage all of this.
Currently we cannot do this since io-thread and main-program-thread are both driving significant logic (would be hard to destroy ISession cleanly and keep io-thread persistent). Additionally, presentation queue requires recreation which is at this moment a free-floating object called pending_results.
What we can do to make the solution to this issue more straight forward though is wait for two changes:
Having #503 implemented is helpful since it would clean up the free-floating pending_results value (messy to manage resetting state for the object)
If main-program-thread is same as io-thread, this means it would be trivial to structure our code such that we can: keep persistent life-time for our io-thread; end/start ISession as needed.
We have a goal where io-thread may receive from client-window a
resetSessionrequest. If this occurs, we should end our ISession and re-create it (and everything should 'just-work'), and keep a persistent io-thread to manage all of this.Currently we cannot do this since io-thread and main-program-thread are both driving significant logic (would be hard to destroy ISession cleanly and keep io-thread persistent). Additionally, presentation queue requires recreation which is at this moment a free-floating object called
pending_results.What we can do to make the solution to this issue more straight forward though is wait for two changes:
ISession#503Having #503 implemented is helpful since it would clean up the free-floating
pending_resultsvalue (messy to manage resetting state for the object)If main-program-thread is same as io-thread, this means it would be trivial to structure our code such that we can: keep persistent life-time for our io-thread; end/start ISession as needed.