Opened at 2009-10-14T00:55:42Z
Last modified at 2023-09-15T03:18:39Z
#318 assigned meta
implement session "subsystem"
| Reported by: | Ichthyostega | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | 0integration |
| Component: | lumieraSteam | Keywords: | interfaces steam session roadmap |
| Sub Tickets: | #209, #319, #497, #685, #700, #701, #956, #1046, #1054 | Parent Tickets: | #305, #320, #1092 |
Description (last modified by )
there is a dummy placeholder "Steam" or "Session" subsystem. Fill in the existing parts of the session to make the session come up when Lumiera starts...
Attachments (1)
Change history (25)
comment:1 by , at 2009-10-14T00:57:15Z
| blockedby: | → 319 |
|---|
comment:2 by , at 2009-10-14T01:03:11Z
| blocking: | 305 → 305, 320 |
|---|
comment:3 by , at 2010-01-02T22:04:35Z
| Keywords: | session added; sesion removed |
|---|
comment:4 by , at 2010-01-07T06:02:13Z
| blockedby: | 319 → 319, 497 |
|---|
comment:5 by , at 2010-01-09T22:41:43Z
| blockedby: | 319, 497 → 319, 497, 518 |
|---|
comment:6 by , at 2010-03-11T22:57:08Z
| blockedby: | 319, 497, 518 → 319, 497 |
|---|
comment:7 by , at 2010-04-02T21:52:59Z
| blocking: | 305, 320 → 209, 305, 320 |
|---|
(In #209) if someone wants to work on this: I'd be happy if something happens on this frontier. Please make sure you understand the design I made for this topic and the interplay with the already implemented command frontend. (read: please ask me to clarify any questions). Otherwise we're bound to waste a lot of effort here.
comment:8 by , at 2010-10-24T02:17:26Z
| blockedby: | 319, 497 → 319, 497, 699 |
|---|
comment:9 by , at 2010-10-24T02:26:28Z
| blockedby: | 319, 497, 699 → 319, 497, 699, 700 |
|---|
comment:10 by , at 2010-10-24T02:31:21Z
| blockedby: | 319, 497, 699, 700 → 319, 497, 699, 700, 701 |
|---|
comment:11 by , at 2011-06-13T21:21:40Z
| blockedby: | 319, 497, 699, 700, 701 → 319, 497, 700, 701 |
|---|
comment:12 by , at 2016-12-09T22:20:45Z
| blockedby: | 319, 497, 700, 701 → 319, 497, 700, 701, 1046 |
|---|
comment:13 by , at 2016-12-12T02:34:26Z
| Status: | new → accepted |
|---|
need to care for this next,
since I need a place actually to open the SessionCommandService
...thus we need a minimal implementation of the "Session subsystem", at least starting and stopping a dedicated thread
comment:14 by , at 2016-12-13T03:49:01Z
initial draft done
- running state is identical with a running
SteamDispatcherloop thread - subsystem just instructs the
SteamDispatchervia the static interface - the
SteamDispatcherloop thread is a PImpl and aThreadJoinable
Note: opening and closing the session is probably independent from running the "session subsystem".
When the session comes up (life-cycle event), the SteamDispater is activated (i.e. accepts commands)
comment:15 by , at 2016-12-20T01:24:55Z
| blockedby: | 319, 497, 700, 701, 1046 → 319, 497, 700, 701, 1046, 1054 |
|---|
comment:16 by , at 2017-01-04T00:47:22Z
TODO identified a locking inconsistency, i.e. problem with subsystem life-cylce problem, leading to deadlock. Need a better way to clean-up the DispatcherLoop after termination of the session loop thread
comment:17 by , at 2017-01-05T02:21:01Z
| Owner: | removed |
|---|---|
| Status: | accepted → assigned |
| Type: | todo → meta |
Work done -- changing to Meta
A bunch of (somewhat tricky) implementation work was necessary to build the structures backing session access and command processing.
Backbone and public interface is in place now, while the actual command processing and builder runs remain to be filled in.
We may now consider to activate the »session subsystem« as part of the application.
For this reason, I'll change this ticket into a meta task now, to keep track of the elements still missing for a basically functional Session implementation.
comment:18 by , at 2017-01-14T07:46:57Z
| blockedby: | 319, 497, 700, 701, 1046, 1054 → 209, 319, 497, 700, 701, 1046, 1054 |
|---|---|
| blocking: | 209, 305, 320 → 305, 320 |
comment:19 by , at 2017-01-14T07:48:31Z
| blockedby: | 209, 319, 497, 700, 701, 1046, 1054 → 209, 319, 497, 700, 701, 956, 1046, 1054 |
|---|
comment:20 by , at 2017-03-18T16:04:51Z
| blocking: | 305, 320 → 305, 320, 1092 |
|---|
comment:21 by , at 2022-10-21T23:28:04Z
| Description: | modified (diff) |
|---|
comment:22 by , at 2023-02-05T03:06:53Z
| Keywords: | roadmap added |
|---|
comment:23 by , at 2023-09-15T03:18:39Z
| blockedby: | 209, 319, 497, 700, 701, 956, 1046, 1054 → 209, 319, 497, 685, 700, 701, 956, 1046, 1054 |
|---|
comment:24 by , at 2025-12-25T00:00:00Z
| blockedby: | 209, 319, 497, 685, 700, 701, 956, 1046, 1054 |
|---|---|
| blocking: | 305, 320, 1092 |
| Parent Tickets: | → 305, 320, 1092 |
| Sub Tickets: | → 209, 319, 497, 685, 700, 701, 956, 1046, 1054 |
Migration MasterTickets ⟼ Subtickets-plugin

(In #518) doesn't block the object references or the first session implementation round. There's a workaround in place for now