Slot queue (#455)
## Slot queue
Adds a slot queue, as per the [slot queue design](https://github.com/codex-storage/codex-research/blob/master/design/sales.md#slot-queue).
Any time storage is requested, all slots from that request are immediately added to the queue. Finished, Canclled, Failed requests remove all slots with that request id from the queue. SlotFreed events add a new slot to the queue and SlotFilled events remove the slot from the queue. This allows popping of a slot each time one is processed, making things much simpler.
When an entire request of slots is added to the queue, the slot indices are shuffled randomly to hopefully prevent nodes that pick up the same storage requested event from clashing on the first processed slot index. This allowed removal of assigning a random slot index in the SalePreparing state and it also ensured that all SalesAgents will have a slot index assigned to them at the start thus the removal of the optional slotIndex.
Remove slotId from SlotFreed event as it was not being used. RequestId and slotIndex were added to the SlotFreed event earlier and those are now being used
The slot queue invariant that prioritises queue items added to the queue relies on a scoring mechanism to sort them based on the [sort order in the design document](https://github.com/codex-storage/codex-research/blob/master/design/sales.md#sort-order).
When a storage request is handled by the sales module, a slot index was randomly assigned and then the slot was filled. Now, a random slot index is only assigned when adding an entire request to the slot queue. Additionally, the slot is checked that its state is `SlotState.Free` before continuing with the download process.
SlotQueue should always ensure the underlying AsyncHeapQueue has one less than the maximum items, ensuring the SlotQueue can always have space to add an additional item regardless if it’s full or not.
Constructing `SlotQueue.workers` in `SlotQueue.new` calls `newAsyncQueue` which causes side effects, so the construction call had to be moved to `SlotQueue.start`.
Prevent loading request from contract (network request) if there is an existing item in queue for that request.
Check availability before adding request to queue.
Add ability to query market contract for past events. When new availabilities are added, the `onReservationAdded` callback is triggered in which past `StorageRequested` events are queried, and those slots are added to the queue (filtered by availability on `push` and filtered by state in `SalePreparing`).
#### Request Workers
Limit the concurrent requests being processed in the queue by using a limited pool of workers (default = 3). Workers are in a data structure of type `AsyncQueue[SlotQueueWorker]`. This allows us to await a `popFirst` for available workers inside of the main SlotQueue event loop
Add an `onCleanUp` that stops the agents and removes them from the sales module agent list. `onCleanUp` is called from sales end states (eg ignored, cancelled, finished, failed, errored).
Add a `doneProcessing` future to `SlotQueueWorker` to be completed in the `OnProcessSlot` callback. Each `doneProcessing` future created is cancelled and awaited in `SlotQueue.stop` (thanks to `TrackableFuturees`), which forced `stop` to become async.
- Cancel dispatched workers and the `onProcessSlot` callbacks, prevents zombie callbacks
#### Add TrackableFutures
Allow tracking of futures in a module so they can be cancelled at a later time. Useful for asyncSpawned futures, but works for any future.
### Sales module
The sales module needed to subscribe to request events to ensure that the request queue was managed correctly on each event. In the process of doing this, the sales agents were updated to avoid subscribing to events in each agent, and instead dispatch received events from the sales module to all created sales agents. This would prevent memory leaks on having too many eventemitters subscribed to.
- prevent removal of agents from sales module while stopping, otherwise the agents seq len is modified while iterating
An additional sales agent state was added, `SalePreparing`, that handles all state machine setup, such as retrieving the request and subscribing to events that were previously in the `SaleDownloading` state.
Once agents have parked in an end state (eg ignored, cancelled, finished, failed, errored), they were not getting cleaned up and the sales module was keeping a handle on their reference. An `onCleanUp` callback was created to be called after the state machine enters an end state, which could prevent a memory leak if the number of requests coming in is high.
Move the SalesAgent callback raises pragmas from the Sales module to the proc definition in SalesAgent. This avoids having to catch `Exception`.
- remove unneeded error handling as pragmas were moved
Move sales.subscriptions from an object containing named subscriptions to a `seq[Subscription]` directly on the sales object.
Sales tests: shut down repo after sales stop, to fix SIGABRT in CI
### Add async Promise API
- modelled after JavaScript Promise API
- alternative to `asyncSpawn` that allows handling of async calls in a synchronous context (including access to the synchronous closure) with less additional procs to be declared
- Write less code, catch errors that would otherwise defect in asyncspawn, and execute a callback after completion
- Add cancellation callbacks to utils/then, ensuring cancellations are handled properly
## Dependencies
- bump codex-contracts-eth to support slot queue (https://github.com/codex-storage/codex-contracts-eth/pull/61)
- bump nim-ethers to 0.5.0
- Bump nim-json-rpc submodule to 0bf2bcb
---------
Co-authored-by: Jaremy Creechley <creechley@gmail.com>
2023-07-25 02:50:30 +00:00
|
|
|
import std/sequtils
|
|
|
|
import std/tables
|
|
|
|
import pkg/chronos
|
|
|
|
import pkg/questionable
|
|
|
|
import pkg/questionable/results
|
|
|
|
import pkg/upraises
|
|
|
|
import ../errors
|
2023-12-19 22:12:47 +00:00
|
|
|
import ../logutils
|
Slot queue (#455)
## Slot queue
Adds a slot queue, as per the [slot queue design](https://github.com/codex-storage/codex-research/blob/master/design/sales.md#slot-queue).
Any time storage is requested, all slots from that request are immediately added to the queue. Finished, Canclled, Failed requests remove all slots with that request id from the queue. SlotFreed events add a new slot to the queue and SlotFilled events remove the slot from the queue. This allows popping of a slot each time one is processed, making things much simpler.
When an entire request of slots is added to the queue, the slot indices are shuffled randomly to hopefully prevent nodes that pick up the same storage requested event from clashing on the first processed slot index. This allowed removal of assigning a random slot index in the SalePreparing state and it also ensured that all SalesAgents will have a slot index assigned to them at the start thus the removal of the optional slotIndex.
Remove slotId from SlotFreed event as it was not being used. RequestId and slotIndex were added to the SlotFreed event earlier and those are now being used
The slot queue invariant that prioritises queue items added to the queue relies on a scoring mechanism to sort them based on the [sort order in the design document](https://github.com/codex-storage/codex-research/blob/master/design/sales.md#sort-order).
When a storage request is handled by the sales module, a slot index was randomly assigned and then the slot was filled. Now, a random slot index is only assigned when adding an entire request to the slot queue. Additionally, the slot is checked that its state is `SlotState.Free` before continuing with the download process.
SlotQueue should always ensure the underlying AsyncHeapQueue has one less than the maximum items, ensuring the SlotQueue can always have space to add an additional item regardless if it’s full or not.
Constructing `SlotQueue.workers` in `SlotQueue.new` calls `newAsyncQueue` which causes side effects, so the construction call had to be moved to `SlotQueue.start`.
Prevent loading request from contract (network request) if there is an existing item in queue for that request.
Check availability before adding request to queue.
Add ability to query market contract for past events. When new availabilities are added, the `onReservationAdded` callback is triggered in which past `StorageRequested` events are queried, and those slots are added to the queue (filtered by availability on `push` and filtered by state in `SalePreparing`).
#### Request Workers
Limit the concurrent requests being processed in the queue by using a limited pool of workers (default = 3). Workers are in a data structure of type `AsyncQueue[SlotQueueWorker]`. This allows us to await a `popFirst` for available workers inside of the main SlotQueue event loop
Add an `onCleanUp` that stops the agents and removes them from the sales module agent list. `onCleanUp` is called from sales end states (eg ignored, cancelled, finished, failed, errored).
Add a `doneProcessing` future to `SlotQueueWorker` to be completed in the `OnProcessSlot` callback. Each `doneProcessing` future created is cancelled and awaited in `SlotQueue.stop` (thanks to `TrackableFuturees`), which forced `stop` to become async.
- Cancel dispatched workers and the `onProcessSlot` callbacks, prevents zombie callbacks
#### Add TrackableFutures
Allow tracking of futures in a module so they can be cancelled at a later time. Useful for asyncSpawned futures, but works for any future.
### Sales module
The sales module needed to subscribe to request events to ensure that the request queue was managed correctly on each event. In the process of doing this, the sales agents were updated to avoid subscribing to events in each agent, and instead dispatch received events from the sales module to all created sales agents. This would prevent memory leaks on having too many eventemitters subscribed to.
- prevent removal of agents from sales module while stopping, otherwise the agents seq len is modified while iterating
An additional sales agent state was added, `SalePreparing`, that handles all state machine setup, such as retrieving the request and subscribing to events that were previously in the `SaleDownloading` state.
Once agents have parked in an end state (eg ignored, cancelled, finished, failed, errored), they were not getting cleaned up and the sales module was keeping a handle on their reference. An `onCleanUp` callback was created to be called after the state machine enters an end state, which could prevent a memory leak if the number of requests coming in is high.
Move the SalesAgent callback raises pragmas from the Sales module to the proc definition in SalesAgent. This avoids having to catch `Exception`.
- remove unneeded error handling as pragmas were moved
Move sales.subscriptions from an object containing named subscriptions to a `seq[Subscription]` directly on the sales object.
Sales tests: shut down repo after sales stop, to fix SIGABRT in CI
### Add async Promise API
- modelled after JavaScript Promise API
- alternative to `asyncSpawn` that allows handling of async calls in a synchronous context (including access to the synchronous closure) with less additional procs to be declared
- Write less code, catch errors that would otherwise defect in asyncspawn, and execute a callback after completion
- Add cancellation callbacks to utils/then, ensuring cancellations are handled properly
## Dependencies
- bump codex-contracts-eth to support slot queue (https://github.com/codex-storage/codex-contracts-eth/pull/61)
- bump nim-ethers to 0.5.0
- Bump nim-json-rpc submodule to 0bf2bcb
---------
Co-authored-by: Jaremy Creechley <creechley@gmail.com>
2023-07-25 02:50:30 +00:00
|
|
|
import ../rng
|
|
|
|
import ../utils
|
|
|
|
import ../contracts/requests
|
|
|
|
import ../utils/asyncheapqueue
|
|
|
|
import ../utils/then
|
2023-07-31 05:09:34 +00:00
|
|
|
import ../utils/trackedfutures
|
Slot queue (#455)
## Slot queue
Adds a slot queue, as per the [slot queue design](https://github.com/codex-storage/codex-research/blob/master/design/sales.md#slot-queue).
Any time storage is requested, all slots from that request are immediately added to the queue. Finished, Canclled, Failed requests remove all slots with that request id from the queue. SlotFreed events add a new slot to the queue and SlotFilled events remove the slot from the queue. This allows popping of a slot each time one is processed, making things much simpler.
When an entire request of slots is added to the queue, the slot indices are shuffled randomly to hopefully prevent nodes that pick up the same storage requested event from clashing on the first processed slot index. This allowed removal of assigning a random slot index in the SalePreparing state and it also ensured that all SalesAgents will have a slot index assigned to them at the start thus the removal of the optional slotIndex.
Remove slotId from SlotFreed event as it was not being used. RequestId and slotIndex were added to the SlotFreed event earlier and those are now being used
The slot queue invariant that prioritises queue items added to the queue relies on a scoring mechanism to sort them based on the [sort order in the design document](https://github.com/codex-storage/codex-research/blob/master/design/sales.md#sort-order).
When a storage request is handled by the sales module, a slot index was randomly assigned and then the slot was filled. Now, a random slot index is only assigned when adding an entire request to the slot queue. Additionally, the slot is checked that its state is `SlotState.Free` before continuing with the download process.
SlotQueue should always ensure the underlying AsyncHeapQueue has one less than the maximum items, ensuring the SlotQueue can always have space to add an additional item regardless if it’s full or not.
Constructing `SlotQueue.workers` in `SlotQueue.new` calls `newAsyncQueue` which causes side effects, so the construction call had to be moved to `SlotQueue.start`.
Prevent loading request from contract (network request) if there is an existing item in queue for that request.
Check availability before adding request to queue.
Add ability to query market contract for past events. When new availabilities are added, the `onReservationAdded` callback is triggered in which past `StorageRequested` events are queried, and those slots are added to the queue (filtered by availability on `push` and filtered by state in `SalePreparing`).
#### Request Workers
Limit the concurrent requests being processed in the queue by using a limited pool of workers (default = 3). Workers are in a data structure of type `AsyncQueue[SlotQueueWorker]`. This allows us to await a `popFirst` for available workers inside of the main SlotQueue event loop
Add an `onCleanUp` that stops the agents and removes them from the sales module agent list. `onCleanUp` is called from sales end states (eg ignored, cancelled, finished, failed, errored).
Add a `doneProcessing` future to `SlotQueueWorker` to be completed in the `OnProcessSlot` callback. Each `doneProcessing` future created is cancelled and awaited in `SlotQueue.stop` (thanks to `TrackableFuturees`), which forced `stop` to become async.
- Cancel dispatched workers and the `onProcessSlot` callbacks, prevents zombie callbacks
#### Add TrackableFutures
Allow tracking of futures in a module so they can be cancelled at a later time. Useful for asyncSpawned futures, but works for any future.
### Sales module
The sales module needed to subscribe to request events to ensure that the request queue was managed correctly on each event. In the process of doing this, the sales agents were updated to avoid subscribing to events in each agent, and instead dispatch received events from the sales module to all created sales agents. This would prevent memory leaks on having too many eventemitters subscribed to.
- prevent removal of agents from sales module while stopping, otherwise the agents seq len is modified while iterating
An additional sales agent state was added, `SalePreparing`, that handles all state machine setup, such as retrieving the request and subscribing to events that were previously in the `SaleDownloading` state.
Once agents have parked in an end state (eg ignored, cancelled, finished, failed, errored), they were not getting cleaned up and the sales module was keeping a handle on their reference. An `onCleanUp` callback was created to be called after the state machine enters an end state, which could prevent a memory leak if the number of requests coming in is high.
Move the SalesAgent callback raises pragmas from the Sales module to the proc definition in SalesAgent. This avoids having to catch `Exception`.
- remove unneeded error handling as pragmas were moved
Move sales.subscriptions from an object containing named subscriptions to a `seq[Subscription]` directly on the sales object.
Sales tests: shut down repo after sales stop, to fix SIGABRT in CI
### Add async Promise API
- modelled after JavaScript Promise API
- alternative to `asyncSpawn` that allows handling of async calls in a synchronous context (including access to the synchronous closure) with less additional procs to be declared
- Write less code, catch errors that would otherwise defect in asyncspawn, and execute a callback after completion
- Add cancellation callbacks to utils/then, ensuring cancellations are handled properly
## Dependencies
- bump codex-contracts-eth to support slot queue (https://github.com/codex-storage/codex-contracts-eth/pull/61)
- bump nim-ethers to 0.5.0
- Bump nim-json-rpc submodule to 0bf2bcb
---------
Co-authored-by: Jaremy Creechley <creechley@gmail.com>
2023-07-25 02:50:30 +00:00
|
|
|
|
|
|
|
logScope:
|
|
|
|
topics = "marketplace slotqueue"
|
|
|
|
|
|
|
|
type
|
|
|
|
OnProcessSlot* =
|
|
|
|
proc(item: SlotQueueItem, done: Future[void]): Future[void] {.gcsafe, upraises:[].}
|
|
|
|
|
|
|
|
# Non-ref obj copies value when assigned, preventing accidental modification
|
|
|
|
# of values which could cause an incorrect order (eg
|
|
|
|
# ``slotQueue[1].collateral = 1`` would cause ``collateral`` to be updated,
|
|
|
|
# but the heap invariant would no longer be honoured. When non-ref, the
|
|
|
|
# compiler can ensure that statement will fail).
|
|
|
|
SlotQueueWorker = object
|
|
|
|
doneProcessing*: Future[void]
|
|
|
|
|
|
|
|
SlotQueueItem* = object
|
|
|
|
requestId: RequestId
|
|
|
|
slotIndex: uint16
|
|
|
|
slotSize: UInt256
|
|
|
|
duration: UInt256
|
|
|
|
reward: UInt256
|
|
|
|
collateral: UInt256
|
|
|
|
expiry: UInt256
|
|
|
|
|
|
|
|
# don't need to -1 to prevent overflow when adding 1 (to always allow push)
|
|
|
|
# because AsyncHeapQueue size is of type `int`, which is larger than `uint16`
|
|
|
|
SlotQueueSize = range[1'u16..uint16.high]
|
|
|
|
|
|
|
|
SlotQueue* = ref object
|
|
|
|
maxWorkers: int
|
|
|
|
onProcessSlot: ?OnProcessSlot
|
|
|
|
queue: AsyncHeapQueue[SlotQueueItem]
|
|
|
|
running: bool
|
|
|
|
workers: AsyncQueue[SlotQueueWorker]
|
|
|
|
trackedFutures: TrackedFutures
|
|
|
|
|
|
|
|
SlotQueueError = object of CodexError
|
|
|
|
SlotQueueItemExistsError* = object of SlotQueueError
|
|
|
|
SlotQueueItemNotExistsError* = object of SlotQueueError
|
|
|
|
SlotsOutOfRangeError* = object of SlotQueueError
|
|
|
|
NoMatchingAvailabilityError* = object of SlotQueueError
|
|
|
|
QueueNotRunningError* = object of SlotQueueError
|
|
|
|
|
|
|
|
# Number of concurrent workers used for processing SlotQueueItems
|
|
|
|
const DefaultMaxWorkers = 3
|
|
|
|
|
|
|
|
# Cap slot queue size to prevent unbounded growth and make sifting more
|
|
|
|
# efficient. Max size is not equivalent to the number of slots a host can
|
|
|
|
# service, which is limited by host availabilities and new requests circulating
|
|
|
|
# the network. Additionally, each new request/slot in the network will be
|
|
|
|
# included in the queue if it is higher priority than any of the exisiting
|
|
|
|
# items. Older slots should be unfillable over time as other hosts fill the
|
|
|
|
# slots.
|
2023-09-04 14:42:09 +00:00
|
|
|
const DefaultMaxSize = 128'u16
|
Slot queue (#455)
## Slot queue
Adds a slot queue, as per the [slot queue design](https://github.com/codex-storage/codex-research/blob/master/design/sales.md#slot-queue).
Any time storage is requested, all slots from that request are immediately added to the queue. Finished, Canclled, Failed requests remove all slots with that request id from the queue. SlotFreed events add a new slot to the queue and SlotFilled events remove the slot from the queue. This allows popping of a slot each time one is processed, making things much simpler.
When an entire request of slots is added to the queue, the slot indices are shuffled randomly to hopefully prevent nodes that pick up the same storage requested event from clashing on the first processed slot index. This allowed removal of assigning a random slot index in the SalePreparing state and it also ensured that all SalesAgents will have a slot index assigned to them at the start thus the removal of the optional slotIndex.
Remove slotId from SlotFreed event as it was not being used. RequestId and slotIndex were added to the SlotFreed event earlier and those are now being used
The slot queue invariant that prioritises queue items added to the queue relies on a scoring mechanism to sort them based on the [sort order in the design document](https://github.com/codex-storage/codex-research/blob/master/design/sales.md#sort-order).
When a storage request is handled by the sales module, a slot index was randomly assigned and then the slot was filled. Now, a random slot index is only assigned when adding an entire request to the slot queue. Additionally, the slot is checked that its state is `SlotState.Free` before continuing with the download process.
SlotQueue should always ensure the underlying AsyncHeapQueue has one less than the maximum items, ensuring the SlotQueue can always have space to add an additional item regardless if it’s full or not.
Constructing `SlotQueue.workers` in `SlotQueue.new` calls `newAsyncQueue` which causes side effects, so the construction call had to be moved to `SlotQueue.start`.
Prevent loading request from contract (network request) if there is an existing item in queue for that request.
Check availability before adding request to queue.
Add ability to query market contract for past events. When new availabilities are added, the `onReservationAdded` callback is triggered in which past `StorageRequested` events are queried, and those slots are added to the queue (filtered by availability on `push` and filtered by state in `SalePreparing`).
#### Request Workers
Limit the concurrent requests being processed in the queue by using a limited pool of workers (default = 3). Workers are in a data structure of type `AsyncQueue[SlotQueueWorker]`. This allows us to await a `popFirst` for available workers inside of the main SlotQueue event loop
Add an `onCleanUp` that stops the agents and removes them from the sales module agent list. `onCleanUp` is called from sales end states (eg ignored, cancelled, finished, failed, errored).
Add a `doneProcessing` future to `SlotQueueWorker` to be completed in the `OnProcessSlot` callback. Each `doneProcessing` future created is cancelled and awaited in `SlotQueue.stop` (thanks to `TrackableFuturees`), which forced `stop` to become async.
- Cancel dispatched workers and the `onProcessSlot` callbacks, prevents zombie callbacks
#### Add TrackableFutures
Allow tracking of futures in a module so they can be cancelled at a later time. Useful for asyncSpawned futures, but works for any future.
### Sales module
The sales module needed to subscribe to request events to ensure that the request queue was managed correctly on each event. In the process of doing this, the sales agents were updated to avoid subscribing to events in each agent, and instead dispatch received events from the sales module to all created sales agents. This would prevent memory leaks on having too many eventemitters subscribed to.
- prevent removal of agents from sales module while stopping, otherwise the agents seq len is modified while iterating
An additional sales agent state was added, `SalePreparing`, that handles all state machine setup, such as retrieving the request and subscribing to events that were previously in the `SaleDownloading` state.
Once agents have parked in an end state (eg ignored, cancelled, finished, failed, errored), they were not getting cleaned up and the sales module was keeping a handle on their reference. An `onCleanUp` callback was created to be called after the state machine enters an end state, which could prevent a memory leak if the number of requests coming in is high.
Move the SalesAgent callback raises pragmas from the Sales module to the proc definition in SalesAgent. This avoids having to catch `Exception`.
- remove unneeded error handling as pragmas were moved
Move sales.subscriptions from an object containing named subscriptions to a `seq[Subscription]` directly on the sales object.
Sales tests: shut down repo after sales stop, to fix SIGABRT in CI
### Add async Promise API
- modelled after JavaScript Promise API
- alternative to `asyncSpawn` that allows handling of async calls in a synchronous context (including access to the synchronous closure) with less additional procs to be declared
- Write less code, catch errors that would otherwise defect in asyncspawn, and execute a callback after completion
- Add cancellation callbacks to utils/then, ensuring cancellations are handled properly
## Dependencies
- bump codex-contracts-eth to support slot queue (https://github.com/codex-storage/codex-contracts-eth/pull/61)
- bump nim-ethers to 0.5.0
- Bump nim-json-rpc submodule to 0bf2bcb
---------
Co-authored-by: Jaremy Creechley <creechley@gmail.com>
2023-07-25 02:50:30 +00:00
|
|
|
|
|
|
|
proc profitability(item: SlotQueueItem): UInt256 =
|
|
|
|
StorageAsk(collateral: item.collateral,
|
|
|
|
duration: item.duration,
|
|
|
|
reward: item.reward,
|
|
|
|
slotSize: item.slotSize).pricePerSlot
|
|
|
|
|
|
|
|
proc `<`*(a, b: SlotQueueItem): bool =
|
|
|
|
# for A to have a higher priority than B (in a min queue), A must be less than
|
|
|
|
# B.
|
|
|
|
var scoreA: uint8 = 0
|
|
|
|
var scoreB: uint8 = 0
|
|
|
|
|
|
|
|
proc addIf(score: var uint8, condition: bool, addition: int) =
|
|
|
|
if condition:
|
|
|
|
score += 1'u8 shl addition
|
|
|
|
|
|
|
|
scoreA.addIf(a.profitability > b.profitability, 3)
|
|
|
|
scoreB.addIf(a.profitability < b.profitability, 3)
|
|
|
|
|
|
|
|
scoreA.addIf(a.collateral < b.collateral, 2)
|
|
|
|
scoreB.addIf(a.collateral > b.collateral, 2)
|
|
|
|
|
|
|
|
scoreA.addIf(a.expiry > b.expiry, 1)
|
|
|
|
scoreB.addIf(a.expiry < b.expiry, 1)
|
|
|
|
|
|
|
|
scoreA.addIf(a.slotSize < b.slotSize, 0)
|
|
|
|
scoreB.addIf(a.slotSize > b.slotSize, 0)
|
|
|
|
|
|
|
|
return scoreA > scoreB
|
|
|
|
|
|
|
|
proc `==`*(a, b: SlotQueueItem): bool =
|
|
|
|
a.requestId == b.requestId and
|
|
|
|
a.slotIndex == b.slotIndex
|
|
|
|
|
|
|
|
proc new*(_: type SlotQueue,
|
|
|
|
maxWorkers = DefaultMaxWorkers,
|
|
|
|
maxSize: SlotQueueSize = DefaultMaxSize): SlotQueue =
|
|
|
|
|
|
|
|
if maxWorkers <= 0:
|
|
|
|
raise newException(ValueError, "maxWorkers must be positive")
|
|
|
|
if maxWorkers.uint16 > maxSize:
|
|
|
|
raise newException(ValueError, "maxWorkers must be less than maxSize")
|
|
|
|
|
|
|
|
SlotQueue(
|
|
|
|
maxWorkers: maxWorkers,
|
|
|
|
# Add 1 to always allow for an extra item to be pushed onto the queue
|
|
|
|
# temporarily. After push (and sort), the bottom-most item will be deleted
|
|
|
|
queue: newAsyncHeapQueue[SlotQueueItem](maxSize.int + 1),
|
|
|
|
running: false,
|
|
|
|
trackedFutures: TrackedFutures.new()
|
|
|
|
)
|
|
|
|
# avoid instantiating `workers` in constructor to avoid side effects in
|
|
|
|
# `newAsyncQueue` procedure
|
|
|
|
|
|
|
|
proc init*(_: type SlotQueueWorker): SlotQueueWorker =
|
|
|
|
SlotQueueWorker(
|
|
|
|
doneProcessing: newFuture[void]("slotqueue.worker.processing")
|
|
|
|
)
|
|
|
|
|
|
|
|
proc init*(_: type SlotQueueItem,
|
|
|
|
requestId: RequestId,
|
|
|
|
slotIndex: uint16,
|
|
|
|
ask: StorageAsk,
|
|
|
|
expiry: UInt256): SlotQueueItem =
|
|
|
|
|
|
|
|
SlotQueueItem(
|
|
|
|
requestId: requestId,
|
|
|
|
slotIndex: slotIndex,
|
|
|
|
slotSize: ask.slotSize,
|
|
|
|
duration: ask.duration,
|
|
|
|
reward: ask.reward,
|
|
|
|
collateral: ask.collateral,
|
|
|
|
expiry: expiry
|
|
|
|
)
|
|
|
|
|
|
|
|
proc init*(_: type SlotQueueItem,
|
|
|
|
request: StorageRequest,
|
|
|
|
slotIndex: uint16): SlotQueueItem =
|
|
|
|
|
|
|
|
SlotQueueItem.init(request.id,
|
|
|
|
slotIndex,
|
|
|
|
request.ask,
|
|
|
|
request.expiry)
|
|
|
|
|
|
|
|
proc init*(_: type SlotQueueItem,
|
|
|
|
requestId: RequestId,
|
|
|
|
ask: StorageAsk,
|
|
|
|
expiry: UInt256): seq[SlotQueueItem] =
|
|
|
|
|
|
|
|
if not ask.slots.inRange:
|
|
|
|
raise newException(SlotsOutOfRangeError, "Too many slots")
|
|
|
|
|
|
|
|
var i = 0'u16
|
|
|
|
proc initSlotQueueItem: SlotQueueItem =
|
|
|
|
let item = SlotQueueItem.init(requestId, i, ask, expiry)
|
|
|
|
inc i
|
|
|
|
return item
|
|
|
|
|
|
|
|
var items = newSeqWith(ask.slots.int, initSlotQueueItem())
|
|
|
|
Rng.instance.shuffle(items)
|
|
|
|
return items
|
|
|
|
|
|
|
|
proc init*(_: type SlotQueueItem,
|
|
|
|
request: StorageRequest): seq[SlotQueueItem] =
|
|
|
|
|
|
|
|
return SlotQueueItem.init(request.id, request.ask, request.expiry)
|
|
|
|
|
|
|
|
proc inRange*(val: SomeUnsignedInt): bool =
|
|
|
|
val.uint16 in SlotQueueSize.low..SlotQueueSize.high
|
|
|
|
|
|
|
|
proc requestId*(self: SlotQueueItem): RequestId = self.requestId
|
|
|
|
proc slotIndex*(self: SlotQueueItem): uint16 = self.slotIndex
|
|
|
|
proc slotSize*(self: SlotQueueItem): UInt256 = self.slotSize
|
|
|
|
proc duration*(self: SlotQueueItem): UInt256 = self.duration
|
|
|
|
proc reward*(self: SlotQueueItem): UInt256 = self.reward
|
|
|
|
proc collateral*(self: SlotQueueItem): UInt256 = self.collateral
|
|
|
|
|
|
|
|
proc running*(self: SlotQueue): bool = self.running
|
|
|
|
|
|
|
|
proc len*(self: SlotQueue): int = self.queue.len
|
|
|
|
|
|
|
|
proc size*(self: SlotQueue): int = self.queue.size - 1
|
|
|
|
|
|
|
|
proc `$`*(self: SlotQueue): string = $self.queue
|
|
|
|
|
|
|
|
proc `onProcessSlot=`*(self: SlotQueue, onProcessSlot: OnProcessSlot) =
|
|
|
|
self.onProcessSlot = some onProcessSlot
|
|
|
|
|
|
|
|
proc activeWorkers*(self: SlotQueue): int =
|
|
|
|
if not self.running: return 0
|
|
|
|
|
|
|
|
# active = capacity - available
|
|
|
|
self.maxWorkers - self.workers.len
|
|
|
|
|
|
|
|
proc contains*(self: SlotQueue, item: SlotQueueItem): bool =
|
|
|
|
self.queue.contains(item)
|
|
|
|
|
|
|
|
proc populateItem*(self: SlotQueue,
|
|
|
|
requestId: RequestId,
|
|
|
|
slotIndex: uint16): ?SlotQueueItem =
|
|
|
|
|
|
|
|
trace "populate item, items in queue", len = self.queue.len
|
|
|
|
for item in self.queue.items:
|
|
|
|
trace "populate item search", itemRequestId = item.requestId, requestId
|
|
|
|
if item.requestId == requestId:
|
|
|
|
return some SlotQueueItem(
|
|
|
|
requestId: requestId,
|
|
|
|
slotIndex: slotIndex,
|
|
|
|
slotSize: item.slotSize,
|
|
|
|
duration: item.duration,
|
|
|
|
reward: item.reward,
|
|
|
|
collateral: item.collateral,
|
|
|
|
expiry: item.expiry
|
|
|
|
)
|
|
|
|
return none SlotQueueItem
|
|
|
|
|
2023-09-04 14:42:09 +00:00
|
|
|
proc push*(self: SlotQueue, item: SlotQueueItem): ?!void =
|
Slot queue (#455)
## Slot queue
Adds a slot queue, as per the [slot queue design](https://github.com/codex-storage/codex-research/blob/master/design/sales.md#slot-queue).
Any time storage is requested, all slots from that request are immediately added to the queue. Finished, Canclled, Failed requests remove all slots with that request id from the queue. SlotFreed events add a new slot to the queue and SlotFilled events remove the slot from the queue. This allows popping of a slot each time one is processed, making things much simpler.
When an entire request of slots is added to the queue, the slot indices are shuffled randomly to hopefully prevent nodes that pick up the same storage requested event from clashing on the first processed slot index. This allowed removal of assigning a random slot index in the SalePreparing state and it also ensured that all SalesAgents will have a slot index assigned to them at the start thus the removal of the optional slotIndex.
Remove slotId from SlotFreed event as it was not being used. RequestId and slotIndex were added to the SlotFreed event earlier and those are now being used
The slot queue invariant that prioritises queue items added to the queue relies on a scoring mechanism to sort them based on the [sort order in the design document](https://github.com/codex-storage/codex-research/blob/master/design/sales.md#sort-order).
When a storage request is handled by the sales module, a slot index was randomly assigned and then the slot was filled. Now, a random slot index is only assigned when adding an entire request to the slot queue. Additionally, the slot is checked that its state is `SlotState.Free` before continuing with the download process.
SlotQueue should always ensure the underlying AsyncHeapQueue has one less than the maximum items, ensuring the SlotQueue can always have space to add an additional item regardless if it’s full or not.
Constructing `SlotQueue.workers` in `SlotQueue.new` calls `newAsyncQueue` which causes side effects, so the construction call had to be moved to `SlotQueue.start`.
Prevent loading request from contract (network request) if there is an existing item in queue for that request.
Check availability before adding request to queue.
Add ability to query market contract for past events. When new availabilities are added, the `onReservationAdded` callback is triggered in which past `StorageRequested` events are queried, and those slots are added to the queue (filtered by availability on `push` and filtered by state in `SalePreparing`).
#### Request Workers
Limit the concurrent requests being processed in the queue by using a limited pool of workers (default = 3). Workers are in a data structure of type `AsyncQueue[SlotQueueWorker]`. This allows us to await a `popFirst` for available workers inside of the main SlotQueue event loop
Add an `onCleanUp` that stops the agents and removes them from the sales module agent list. `onCleanUp` is called from sales end states (eg ignored, cancelled, finished, failed, errored).
Add a `doneProcessing` future to `SlotQueueWorker` to be completed in the `OnProcessSlot` callback. Each `doneProcessing` future created is cancelled and awaited in `SlotQueue.stop` (thanks to `TrackableFuturees`), which forced `stop` to become async.
- Cancel dispatched workers and the `onProcessSlot` callbacks, prevents zombie callbacks
#### Add TrackableFutures
Allow tracking of futures in a module so they can be cancelled at a later time. Useful for asyncSpawned futures, but works for any future.
### Sales module
The sales module needed to subscribe to request events to ensure that the request queue was managed correctly on each event. In the process of doing this, the sales agents were updated to avoid subscribing to events in each agent, and instead dispatch received events from the sales module to all created sales agents. This would prevent memory leaks on having too many eventemitters subscribed to.
- prevent removal of agents from sales module while stopping, otherwise the agents seq len is modified while iterating
An additional sales agent state was added, `SalePreparing`, that handles all state machine setup, such as retrieving the request and subscribing to events that were previously in the `SaleDownloading` state.
Once agents have parked in an end state (eg ignored, cancelled, finished, failed, errored), they were not getting cleaned up and the sales module was keeping a handle on their reference. An `onCleanUp` callback was created to be called after the state machine enters an end state, which could prevent a memory leak if the number of requests coming in is high.
Move the SalesAgent callback raises pragmas from the Sales module to the proc definition in SalesAgent. This avoids having to catch `Exception`.
- remove unneeded error handling as pragmas were moved
Move sales.subscriptions from an object containing named subscriptions to a `seq[Subscription]` directly on the sales object.
Sales tests: shut down repo after sales stop, to fix SIGABRT in CI
### Add async Promise API
- modelled after JavaScript Promise API
- alternative to `asyncSpawn` that allows handling of async calls in a synchronous context (including access to the synchronous closure) with less additional procs to be declared
- Write less code, catch errors that would otherwise defect in asyncspawn, and execute a callback after completion
- Add cancellation callbacks to utils/then, ensuring cancellations are handled properly
## Dependencies
- bump codex-contracts-eth to support slot queue (https://github.com/codex-storage/codex-contracts-eth/pull/61)
- bump nim-ethers to 0.5.0
- Bump nim-json-rpc submodule to 0bf2bcb
---------
Co-authored-by: Jaremy Creechley <creechley@gmail.com>
2023-07-25 02:50:30 +00:00
|
|
|
|
|
|
|
trace "pushing item to queue",
|
|
|
|
requestId = item.requestId, slotIndex = item.slotIndex
|
|
|
|
|
|
|
|
if not self.running:
|
|
|
|
let err = newException(QueueNotRunningError, "queue not running")
|
|
|
|
return failure(err)
|
|
|
|
|
|
|
|
if self.contains(item):
|
|
|
|
let err = newException(SlotQueueItemExistsError, "item already exists")
|
|
|
|
return failure(err)
|
|
|
|
|
|
|
|
if err =? self.queue.pushNoWait(item).mapFailure.errorOption:
|
|
|
|
return failure(err)
|
|
|
|
|
|
|
|
if self.queue.full():
|
|
|
|
# delete the last item
|
|
|
|
self.queue.del(self.queue.size - 1)
|
|
|
|
|
|
|
|
doAssert self.queue.len <= self.queue.size - 1
|
|
|
|
return success()
|
|
|
|
|
2023-09-04 14:42:09 +00:00
|
|
|
proc push*(self: SlotQueue, items: seq[SlotQueueItem]): ?!void =
|
Slot queue (#455)
## Slot queue
Adds a slot queue, as per the [slot queue design](https://github.com/codex-storage/codex-research/blob/master/design/sales.md#slot-queue).
Any time storage is requested, all slots from that request are immediately added to the queue. Finished, Canclled, Failed requests remove all slots with that request id from the queue. SlotFreed events add a new slot to the queue and SlotFilled events remove the slot from the queue. This allows popping of a slot each time one is processed, making things much simpler.
When an entire request of slots is added to the queue, the slot indices are shuffled randomly to hopefully prevent nodes that pick up the same storage requested event from clashing on the first processed slot index. This allowed removal of assigning a random slot index in the SalePreparing state and it also ensured that all SalesAgents will have a slot index assigned to them at the start thus the removal of the optional slotIndex.
Remove slotId from SlotFreed event as it was not being used. RequestId and slotIndex were added to the SlotFreed event earlier and those are now being used
The slot queue invariant that prioritises queue items added to the queue relies on a scoring mechanism to sort them based on the [sort order in the design document](https://github.com/codex-storage/codex-research/blob/master/design/sales.md#sort-order).
When a storage request is handled by the sales module, a slot index was randomly assigned and then the slot was filled. Now, a random slot index is only assigned when adding an entire request to the slot queue. Additionally, the slot is checked that its state is `SlotState.Free` before continuing with the download process.
SlotQueue should always ensure the underlying AsyncHeapQueue has one less than the maximum items, ensuring the SlotQueue can always have space to add an additional item regardless if it’s full or not.
Constructing `SlotQueue.workers` in `SlotQueue.new` calls `newAsyncQueue` which causes side effects, so the construction call had to be moved to `SlotQueue.start`.
Prevent loading request from contract (network request) if there is an existing item in queue for that request.
Check availability before adding request to queue.
Add ability to query market contract for past events. When new availabilities are added, the `onReservationAdded` callback is triggered in which past `StorageRequested` events are queried, and those slots are added to the queue (filtered by availability on `push` and filtered by state in `SalePreparing`).
#### Request Workers
Limit the concurrent requests being processed in the queue by using a limited pool of workers (default = 3). Workers are in a data structure of type `AsyncQueue[SlotQueueWorker]`. This allows us to await a `popFirst` for available workers inside of the main SlotQueue event loop
Add an `onCleanUp` that stops the agents and removes them from the sales module agent list. `onCleanUp` is called from sales end states (eg ignored, cancelled, finished, failed, errored).
Add a `doneProcessing` future to `SlotQueueWorker` to be completed in the `OnProcessSlot` callback. Each `doneProcessing` future created is cancelled and awaited in `SlotQueue.stop` (thanks to `TrackableFuturees`), which forced `stop` to become async.
- Cancel dispatched workers and the `onProcessSlot` callbacks, prevents zombie callbacks
#### Add TrackableFutures
Allow tracking of futures in a module so they can be cancelled at a later time. Useful for asyncSpawned futures, but works for any future.
### Sales module
The sales module needed to subscribe to request events to ensure that the request queue was managed correctly on each event. In the process of doing this, the sales agents were updated to avoid subscribing to events in each agent, and instead dispatch received events from the sales module to all created sales agents. This would prevent memory leaks on having too many eventemitters subscribed to.
- prevent removal of agents from sales module while stopping, otherwise the agents seq len is modified while iterating
An additional sales agent state was added, `SalePreparing`, that handles all state machine setup, such as retrieving the request and subscribing to events that were previously in the `SaleDownloading` state.
Once agents have parked in an end state (eg ignored, cancelled, finished, failed, errored), they were not getting cleaned up and the sales module was keeping a handle on their reference. An `onCleanUp` callback was created to be called after the state machine enters an end state, which could prevent a memory leak if the number of requests coming in is high.
Move the SalesAgent callback raises pragmas from the Sales module to the proc definition in SalesAgent. This avoids having to catch `Exception`.
- remove unneeded error handling as pragmas were moved
Move sales.subscriptions from an object containing named subscriptions to a `seq[Subscription]` directly on the sales object.
Sales tests: shut down repo after sales stop, to fix SIGABRT in CI
### Add async Promise API
- modelled after JavaScript Promise API
- alternative to `asyncSpawn` that allows handling of async calls in a synchronous context (including access to the synchronous closure) with less additional procs to be declared
- Write less code, catch errors that would otherwise defect in asyncspawn, and execute a callback after completion
- Add cancellation callbacks to utils/then, ensuring cancellations are handled properly
## Dependencies
- bump codex-contracts-eth to support slot queue (https://github.com/codex-storage/codex-contracts-eth/pull/61)
- bump nim-ethers to 0.5.0
- Bump nim-json-rpc submodule to 0bf2bcb
---------
Co-authored-by: Jaremy Creechley <creechley@gmail.com>
2023-07-25 02:50:30 +00:00
|
|
|
for item in items:
|
2023-09-04 14:42:09 +00:00
|
|
|
if err =? self.push(item).errorOption:
|
Slot queue (#455)
## Slot queue
Adds a slot queue, as per the [slot queue design](https://github.com/codex-storage/codex-research/blob/master/design/sales.md#slot-queue).
Any time storage is requested, all slots from that request are immediately added to the queue. Finished, Canclled, Failed requests remove all slots with that request id from the queue. SlotFreed events add a new slot to the queue and SlotFilled events remove the slot from the queue. This allows popping of a slot each time one is processed, making things much simpler.
When an entire request of slots is added to the queue, the slot indices are shuffled randomly to hopefully prevent nodes that pick up the same storage requested event from clashing on the first processed slot index. This allowed removal of assigning a random slot index in the SalePreparing state and it also ensured that all SalesAgents will have a slot index assigned to them at the start thus the removal of the optional slotIndex.
Remove slotId from SlotFreed event as it was not being used. RequestId and slotIndex were added to the SlotFreed event earlier and those are now being used
The slot queue invariant that prioritises queue items added to the queue relies on a scoring mechanism to sort them based on the [sort order in the design document](https://github.com/codex-storage/codex-research/blob/master/design/sales.md#sort-order).
When a storage request is handled by the sales module, a slot index was randomly assigned and then the slot was filled. Now, a random slot index is only assigned when adding an entire request to the slot queue. Additionally, the slot is checked that its state is `SlotState.Free` before continuing with the download process.
SlotQueue should always ensure the underlying AsyncHeapQueue has one less than the maximum items, ensuring the SlotQueue can always have space to add an additional item regardless if it’s full or not.
Constructing `SlotQueue.workers` in `SlotQueue.new` calls `newAsyncQueue` which causes side effects, so the construction call had to be moved to `SlotQueue.start`.
Prevent loading request from contract (network request) if there is an existing item in queue for that request.
Check availability before adding request to queue.
Add ability to query market contract for past events. When new availabilities are added, the `onReservationAdded` callback is triggered in which past `StorageRequested` events are queried, and those slots are added to the queue (filtered by availability on `push` and filtered by state in `SalePreparing`).
#### Request Workers
Limit the concurrent requests being processed in the queue by using a limited pool of workers (default = 3). Workers are in a data structure of type `AsyncQueue[SlotQueueWorker]`. This allows us to await a `popFirst` for available workers inside of the main SlotQueue event loop
Add an `onCleanUp` that stops the agents and removes them from the sales module agent list. `onCleanUp` is called from sales end states (eg ignored, cancelled, finished, failed, errored).
Add a `doneProcessing` future to `SlotQueueWorker` to be completed in the `OnProcessSlot` callback. Each `doneProcessing` future created is cancelled and awaited in `SlotQueue.stop` (thanks to `TrackableFuturees`), which forced `stop` to become async.
- Cancel dispatched workers and the `onProcessSlot` callbacks, prevents zombie callbacks
#### Add TrackableFutures
Allow tracking of futures in a module so they can be cancelled at a later time. Useful for asyncSpawned futures, but works for any future.
### Sales module
The sales module needed to subscribe to request events to ensure that the request queue was managed correctly on each event. In the process of doing this, the sales agents were updated to avoid subscribing to events in each agent, and instead dispatch received events from the sales module to all created sales agents. This would prevent memory leaks on having too many eventemitters subscribed to.
- prevent removal of agents from sales module while stopping, otherwise the agents seq len is modified while iterating
An additional sales agent state was added, `SalePreparing`, that handles all state machine setup, such as retrieving the request and subscribing to events that were previously in the `SaleDownloading` state.
Once agents have parked in an end state (eg ignored, cancelled, finished, failed, errored), they were not getting cleaned up and the sales module was keeping a handle on their reference. An `onCleanUp` callback was created to be called after the state machine enters an end state, which could prevent a memory leak if the number of requests coming in is high.
Move the SalesAgent callback raises pragmas from the Sales module to the proc definition in SalesAgent. This avoids having to catch `Exception`.
- remove unneeded error handling as pragmas were moved
Move sales.subscriptions from an object containing named subscriptions to a `seq[Subscription]` directly on the sales object.
Sales tests: shut down repo after sales stop, to fix SIGABRT in CI
### Add async Promise API
- modelled after JavaScript Promise API
- alternative to `asyncSpawn` that allows handling of async calls in a synchronous context (including access to the synchronous closure) with less additional procs to be declared
- Write less code, catch errors that would otherwise defect in asyncspawn, and execute a callback after completion
- Add cancellation callbacks to utils/then, ensuring cancellations are handled properly
## Dependencies
- bump codex-contracts-eth to support slot queue (https://github.com/codex-storage/codex-contracts-eth/pull/61)
- bump nim-ethers to 0.5.0
- Bump nim-json-rpc submodule to 0bf2bcb
---------
Co-authored-by: Jaremy Creechley <creechley@gmail.com>
2023-07-25 02:50:30 +00:00
|
|
|
return failure(err)
|
|
|
|
|
|
|
|
return success()
|
|
|
|
|
|
|
|
proc findByRequest(self: SlotQueue, requestId: RequestId): seq[SlotQueueItem] =
|
|
|
|
var items: seq[SlotQueueItem] = @[]
|
|
|
|
for item in self.queue.items:
|
|
|
|
if item.requestId == requestId:
|
|
|
|
items.add item
|
|
|
|
return items
|
|
|
|
|
|
|
|
proc delete*(self: SlotQueue, item: SlotQueueItem) =
|
|
|
|
logScope:
|
|
|
|
requestId = item.requestId
|
|
|
|
slotIndex = item.slotIndex
|
|
|
|
|
|
|
|
trace "removing item from queue"
|
|
|
|
|
|
|
|
if not self.running:
|
|
|
|
trace "cannot delete item from queue, queue not running"
|
|
|
|
return
|
|
|
|
|
|
|
|
self.queue.delete(item)
|
|
|
|
|
|
|
|
proc delete*(self: SlotQueue, requestId: RequestId, slotIndex: uint16) =
|
|
|
|
let item = SlotQueueItem(requestId: requestId, slotIndex: slotIndex)
|
|
|
|
self.delete(item)
|
|
|
|
|
|
|
|
proc delete*(self: SlotQueue, requestId: RequestId) =
|
|
|
|
let items = self.findByRequest(requestId)
|
|
|
|
for item in items:
|
|
|
|
self.delete(item)
|
|
|
|
|
|
|
|
proc `[]`*(self: SlotQueue, i: Natural): SlotQueueItem =
|
|
|
|
self.queue[i]
|
|
|
|
|
|
|
|
proc addWorker(self: SlotQueue): ?!void =
|
|
|
|
if not self.running:
|
|
|
|
let err = newException(QueueNotRunningError, "queue must be running")
|
|
|
|
return failure(err)
|
|
|
|
|
|
|
|
trace "adding new worker to worker queue"
|
|
|
|
|
|
|
|
let worker = SlotQueueWorker.init()
|
|
|
|
try:
|
|
|
|
self.workers.addLastNoWait(worker)
|
|
|
|
except AsyncQueueFullError:
|
|
|
|
return failure("failed to add worker, worker queue full")
|
|
|
|
|
|
|
|
return success()
|
|
|
|
|
|
|
|
proc dispatch(self: SlotQueue,
|
|
|
|
worker: SlotQueueWorker,
|
|
|
|
item: SlotQueueItem) {.async.} =
|
|
|
|
logScope:
|
|
|
|
requestId = item.requestId
|
|
|
|
slotIndex = item.slotIndex
|
|
|
|
|
|
|
|
if not self.running:
|
|
|
|
warn "Could not dispatch worker because queue is not running"
|
|
|
|
return
|
|
|
|
|
|
|
|
if onProcessSlot =? self.onProcessSlot:
|
|
|
|
try:
|
|
|
|
await onProcessSlot(item, worker.doneProcessing)
|
|
|
|
await worker.doneProcessing
|
|
|
|
|
|
|
|
if err =? self.addWorker().errorOption:
|
|
|
|
raise err # catch below
|
|
|
|
|
|
|
|
except QueueNotRunningError as e:
|
|
|
|
info "could not re-add worker to worker queue, queue not running",
|
|
|
|
error = e.msg
|
|
|
|
except CancelledError:
|
|
|
|
# do not bubble exception up as it is called with `asyncSpawn` which would
|
|
|
|
# convert the exception into a `FutureDefect`
|
|
|
|
discard
|
|
|
|
except CatchableError as e:
|
|
|
|
# we don't have any insight into types of errors that `onProcessSlot` can
|
|
|
|
# throw because it is caller-defined
|
|
|
|
warn "Unknown error processing slot in worker", error = e.msg
|
|
|
|
|
|
|
|
proc start*(self: SlotQueue) {.async.} =
|
|
|
|
if self.running:
|
|
|
|
return
|
|
|
|
|
|
|
|
trace "starting slot queue"
|
|
|
|
|
|
|
|
self.running = true
|
|
|
|
|
|
|
|
# must be called in `start` to avoid sideeffects in `new`
|
|
|
|
self.workers = newAsyncQueue[SlotQueueWorker](self.maxWorkers)
|
|
|
|
|
|
|
|
# Add initial workers to the `AsyncHeapQueue`. Once a worker has completed its
|
|
|
|
# task, a new worker will be pushed to the queue
|
|
|
|
for i in 0..<self.maxWorkers:
|
|
|
|
if err =? self.addWorker().errorOption:
|
|
|
|
error "start: error adding new worker", error = err.msg
|
|
|
|
|
|
|
|
while self.running:
|
|
|
|
try:
|
|
|
|
let worker = await self.workers.popFirst().track(self) # if workers saturated, wait here for new workers
|
|
|
|
let item = await self.queue.pop().track(self) # if queue empty, wait here for new items
|
|
|
|
|
|
|
|
if not self.running: # may have changed after waiting for pop
|
|
|
|
trace "not running, exiting"
|
|
|
|
break
|
|
|
|
|
|
|
|
self.dispatch(worker, item)
|
|
|
|
.track(self)
|
|
|
|
.catch(proc (e: ref CatchableError) =
|
|
|
|
error "Unknown error dispatching worker", error = e.msg
|
|
|
|
)
|
|
|
|
|
|
|
|
discard worker.doneProcessing.track(self)
|
|
|
|
|
|
|
|
await sleepAsync(1.millis) # poll
|
|
|
|
except CancelledError:
|
|
|
|
discard
|
|
|
|
except CatchableError as e: # raised from self.queue.pop() or self.workers.pop()
|
|
|
|
warn "slot queue error encountered during processing", error = e.msg
|
|
|
|
|
|
|
|
proc stop*(self: SlotQueue) {.async.} =
|
|
|
|
if not self.running:
|
|
|
|
return
|
|
|
|
|
|
|
|
trace "stopping slot queue"
|
|
|
|
|
|
|
|
self.running = false
|
|
|
|
|
|
|
|
await self.trackedFutures.cancelTracked()
|