Summary:
Pull Request resolved: https://github.com/facebook/Haxl/pull/109
FutureFetch is unused (except for one test) and overall has not proven itself to be a useful fetch type. It adds a new waiting point (the others being BackgroundFetch and Async/Sync fetches) which can add latency. For example if all three are dispatched in one round how would the scheduler know ahead of time which one to wait on in order to make forward progress.
Reviewed By: simonmar
Differential Revision: D19410093
fbshipit-source-id: 40c900fbff9e06098acb2a21fc59b49adefadc5b
Summary: Bump the minimum Haxl version to GHC 8.2, which at this point is 2.5 years old but more importantly has many features that are really helpful in Haxl (such as the hs_try_put_mvar API function, which is really useful for BackgroundFetch)
Reviewed By: josefs
Differential Revision: D19327952
fbshipit-source-id: f635068fe9fb8f1d1f0d83ccbf9c3c04947183a0
Summary:
Expose a conveniece wrapper `runHaxlWithWrites` which returns the writes along with
the result of the `Haxl` computation.
Reviewed By: simonmar
Differential Revision: D14386668
fbshipit-source-id: 95757916691f7b9b1291c7dceae7eafe8738cfca
Summary:
Here I try to populate the writes done as part of a Haxl computation
in an IORef inside the Environment.
`IVar` which is the synchornisation point,
also acts as the point where we store intermediate writes for Haxl
computations, so they can be memoized and reused whenever a memoized
computation is done again. This is done inside `getIVarWithWrites` function.
This works, because we create new IVars when running a memo computation
or a data fetch, and it is only at these places where we need to create a new
environment with empty writes to run the computation in. So I run every memoized
computation in a new environment (with empty writes) and populate the writes in this new
environment. At the end of the memoized computation, I look up these writes from the `IVar`
and also add them to the original environment. This way ultimately all writes are correctly
propagated upwards to the top level environment user passes to `runHaxl`.
This logic lives inside `execMemoNow`.
Reviewed By: simonmar
Differential Revision: D14342181
fbshipit-source-id: a410dae1a477f27b480804b67b2212e7500997ab
Summary:
This is a complete reworking of the way that Haxl schedules I/O. The
main benefits are:
* Data fetches are no longer organised into rounds, but can be
arbitrarily overlapped with each other and with computation. The
scheduler supports an arbitrary queue of work items which it can
evaluate while data-fetching is taking place in the background. To
take advantage of this, data sources must implement a new form of
`PerformFetch`, namely `BackgroundFetch`. The old forms of
`PerformFetch` are still supported, but won't benefit from any
additional concurrency.
* It is now possible to specify on a per-data-source basis whether
fetching should be optimised for batching or for latency. A request
to a data source that doesn't benefit from batching can be submitted
immediately. This is done with the new `schedulerHint` method of
`DataSource`.
Reviewed By: niteria
Differential Revision: D4938005
fbshipit-source-id: 96f12ad05ee62d62474ee4cc1215f19d0a6fcdf3
When building from a fresh sandbox in /example/sql, cabal complained
about the name and version fields missing, as well as the base
dependency missing in build-depends.
