[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-bugs] #24554 [Core Tor/Tor]: sched: Have per-scheduler type data in a channel_t
#24554: sched: Have per-scheduler type data in a channel_t
------------------------------+--------------------------------
Reporter: dgoulet | Owner: dgoulet
Type: enhancement | Status: assigned
Priority: Medium | Milestone: Tor: 0.3.3.x-final
Component: Core Tor/Tor | Version:
Severity: Normal | Keywords: tor-sched
Actual Points: | Parent ID:
Points: | Reviewer:
Sponsor: |
------------------------------+--------------------------------
Right now in `channel_t`, we have a `sched_heap_idx` and
`scheduler_state`. Both are specific to the scheduler layer and are per-
channel. The KIST scheduler also keeps data per-channel in a global state
it keeps some other place.
Because of #23744, which is a ticket about the scheduler state not
applying to both Vanilla and KIST, we need a way to have a interface that
allows any "scheduler data per-channel" to be specific to a type of
scheduler (KIST or Vanilla).
To achieve compartmentalization of whatever state the scheduler needs to
keep, we need an interface that allows a specific scheduler to store data
per-channel instead of in a global state which, in the case of KIST, would
avoid two things:
1. Huge amount of memory allocation at runtime that needs to be done by
the main loop (this is currently a problem with KIST code).
2. Avoid data duplication or/and synchronization problem between the
channel subsystem and the scheduler subsystem.
Finally, by doing so, we can build an opaque interface for the specific
scheduler information data structure in order to make them *ONLY*
accessible from the per-type scheduler code. This means a builtin
protection to prevent any other layer in the tor to change or access the
channel's scheduler state.
Once we have this capability, we can go ahead and fix #23744 and move the
`sched_heap_idx` and `scheduler_state` out of a channel object so ONLY the
scheduler has access to those and be able to have different semantic for
different scheduler type.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24554>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs