You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Given that results are streaming to a channel, using a context instead of a hard timeout would be more appropriate. Working with a hard timeout within the concurrency model set up in this library somewhat awkward and limiting. For example what if I want to read entries from a channel until I find all of the entries I am looking for and then move on? Currently to do this you either have to:
Choose an overly long timeout and be okay with the goroutine running Query not exiting until potentially long after its task has be fulfilled
Repeat calls to Query with a short timeout in a loop
1 means sacrificing performance and even if its unlikely to be a bottleneck in your applications resource use its still pretty grating to anyone who cares about good design. Whereas 2 feels like over-engineering due to utilizing a clunky API.
Having these functions take a context would allow library users to readily choose whether they want to use the timeout model or logic driven cancellation using well defined and understood patterns from the go standard library.
The text was updated successfully, but these errors were encountered:
Given that results are streaming to a channel, using a context instead of a hard timeout would be more appropriate. Working with a hard timeout within the concurrency model set up in this library somewhat awkward and limiting. For example what if I want to read entries from a channel until I find all of the entries I am looking for and then move on? Currently to do this you either have to:
Query
not exiting until potentially long after its task has be fulfilledQuery
with a short timeout in a loop1
means sacrificing performance and even if its unlikely to be a bottleneck in your applications resource use its still pretty grating to anyone who cares about good design. Whereas2
feels like over-engineering due to utilizing a clunky API.Having these functions take a
context
would allow library users to readily choose whether they want to use the timeout model or logic driven cancellation using well defined and understood patterns from thego
standard library.The text was updated successfully, but these errors were encountered: