-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Async hist loading #287
Async hist loading #287
Conversation
Break up real-time quote feed and history loading into 2 separate tasks and deliver a client side `data.Feed` as soon as history is loaded (instead of waiting for a rt quote - the previous logic). If a symbol doesn't have history then likely the feed shouldn't be loaded (since presumably client code will need at least "some" datums history to do anything) and waiting on a real-time quote is dumb, since it'll hang if the market isn't open XD. If a symbol doesn't have history we can always write a zero/null array when we run into that case. This also greatly speeds up feed loading when both history and quotes are available. TL;DR summary: - add a `_Feedsbus.start_task()` one-cancel-scope-per-task method for assisting with (re-)starting and stopping long running persistent feeds (basically a "one cancels one" style nursery API). - add a `manage_history()` task which does all history loading (and eventually real-time writing) which has an independent signal and start it in a separate task. - drop the "sample rate per symbol" stuff since client code doesn't really care when it can just inspect shm indexing/time-steps itself. - run throttle tasks in the bus nursery thus avoiding cancelling the underlying sampler task on feed client disconnects. - don't store a repeated ref the bus nursery's cancel scope..
Since moving to a "god loop" for graphics, we don't really need to have a dedicated task for updating graphics on new sample increments. The only UX difference will be that curves won't be updated until an actual new rt-quote-event triggers the graphics loop -> so we'll have the chart "jump" to a new position and new curve segments generated only when new data arrives. This is imo fine since it's just less "idle" updates where the chart would sit printing the same (last) value every step. Instead only update the view increment if a new index is detected by reading shm. If we ever want this dedicated task update again this commit can be easily reverted B)
@@ -447,3 +494,25 @@ async def maybe_open_emsd( | |||
|
|||
) as portal: | |||
yield portal | |||
|
|||
|
|||
# TODO: ideally we can start the tsdb "on demand" but it's |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Obvs coming down the road as part of what results from #247, left in as a guide.
# are diffed on each draw cycle anyway; so updates to the | ||
# "curve" length is already automatic. | ||
|
||
# increment the view position by the sample offset. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is less costly then a task context switch and gives a more "lazy" UX then the below left dedicated "update task" approach.
@@ -381,14 +380,19 @@ async def poll_and_sync_to_step( | |||
|
|||
s, step, ld = is_synced(src, dst) | |||
|
|||
# detect sample period step for subscription to increment | |||
# signal | |||
times = src.array['time'] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'll probably want a standard api for this eventually?
piker/data/feed.py
Outdated
trio.CancelScope] = trio.TASK_STATUS_IGNORED, | ||
) -> None: | ||
with trio.CancelScope() as cs: | ||
self.nursery.start_soon( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should probably move this to be a self.nusery.start()
for now until python-trio/trio#2258 is resolved.
piker/data/feed.py
Outdated
''' | ||
# TODO: history retreival, see if we can pull from an existing | ||
# ``marketstored`` daemon | ||
log.info('Scanning for existing `marketstored`') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Woops, this should probably get commented.
Obviously these imports will come in with #247.
piker/data/feed.py
Outdated
|
||
if opened: | ||
if arrays: | ||
await tractor.breakpoint() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just placeholder for #247 work.
Re-work of the
piker.data.feed
machinery to do async loading of both real-time and historical data for faster chart startup and a better setup to get the work from #93 landed.Part of this work discovered the unexpected behavior that is python-trio/trio#2258.
Included are a bunch of other changes summarized by "topic":
miscellaneous fixups
msgpack
andmsgpack-numpy
open_piker_runtime()
to make it easy to write a client that uses all thetractor
apis correctlydata feed rework
ShmArray
s to the backendstream_quotes()
endpoints since they don't manually write themselvesopen_feed()
without requiring a real-time quote stream (eg. just for accessing shm / history)misc graphics
ChartPlotWidget.increment_view()
take asteps: int
mamin()
range calcer to not crash on no-data-in-view