Add job queue (fixes #629)
Request to terminate currently ongoing downloads and jump to the bumped file
incoming in 3, 2, 1.
Also, has a slightly strange effect where we pop a job off the queue, but
the copyChannel is still busy and blocks, though it gets moved to the
progress slice in the jobqueue, and looks like it's in progress which it isn't
as it's waiting to be picked up from the copyChan.
As a result, the progress emitter doesn't register on the task, and hence the file
doesn't have a progress bar, but cannot be replaced by a bump.
I guess I can fix progress bar issue by moving the progressEmiter.Register just
before passing the file to the copyChan, but then we are back to the initial
problem of a file with a progress bar, but no progress happening as it's stuck
on write to copyChan
I checked if there is a way to check for channel writeability (before popping)
but got struck by lightning just for bringing the idea up in #go-nuts.
My ideal scenario would be to check if copyChan is writeable, pop job from the
queue and shove it down handleFile. This way jobs would stay in the queue while
they cannot be handled, meaning that the `Bump` could bring your file up higher.
2014-12-01 19:23:06 +00:00
|
|
|
// Copyright (C) 2014 The Syncthing Authors.
|
|
|
|
//
|
2015-03-07 20:36:35 +00:00
|
|
|
// This Source Code Form is subject to the terms of the Mozilla Public
|
|
|
|
// License, v. 2.0. If a copy of the MPL was not distributed with this file,
|
2017-02-09 06:52:18 +00:00
|
|
|
// You can obtain one at https://mozilla.org/MPL/2.0/.
|
Add job queue (fixes #629)
Request to terminate currently ongoing downloads and jump to the bumped file
incoming in 3, 2, 1.
Also, has a slightly strange effect where we pop a job off the queue, but
the copyChannel is still busy and blocks, though it gets moved to the
progress slice in the jobqueue, and looks like it's in progress which it isn't
as it's waiting to be picked up from the copyChan.
As a result, the progress emitter doesn't register on the task, and hence the file
doesn't have a progress bar, but cannot be replaced by a bump.
I guess I can fix progress bar issue by moving the progressEmiter.Register just
before passing the file to the copyChan, but then we are back to the initial
problem of a file with a progress bar, but no progress happening as it's stuck
on write to copyChan
I checked if there is a way to check for channel writeability (before popping)
but got struck by lightning just for bringing the idea up in #go-nuts.
My ideal scenario would be to check if copyChan is writeable, pop job from the
queue and shove it down handleFile. This way jobs would stay in the queue while
they cannot be handled, meaning that the `Bump` could bring your file up higher.
2014-12-01 19:23:06 +00:00
|
|
|
|
|
|
|
package model
|
|
|
|
|
2015-04-25 05:13:53 +00:00
|
|
|
import (
|
|
|
|
"sort"
|
2016-08-06 13:05:59 +00:00
|
|
|
"time"
|
2015-04-25 05:13:53 +00:00
|
|
|
|
2019-05-29 07:56:40 +00:00
|
|
|
"github.com/syncthing/syncthing/lib/rand"
|
2015-08-06 09:29:25 +00:00
|
|
|
"github.com/syncthing/syncthing/lib/sync"
|
2015-04-25 05:13:53 +00:00
|
|
|
)
|
Add job queue (fixes #629)
Request to terminate currently ongoing downloads and jump to the bumped file
incoming in 3, 2, 1.
Also, has a slightly strange effect where we pop a job off the queue, but
the copyChannel is still busy and blocks, though it gets moved to the
progress slice in the jobqueue, and looks like it's in progress which it isn't
as it's waiting to be picked up from the copyChan.
As a result, the progress emitter doesn't register on the task, and hence the file
doesn't have a progress bar, but cannot be replaced by a bump.
I guess I can fix progress bar issue by moving the progressEmiter.Register just
before passing the file to the copyChan, but then we are back to the initial
problem of a file with a progress bar, but no progress happening as it's stuck
on write to copyChan
I checked if there is a way to check for channel writeability (before popping)
but got struck by lightning just for bringing the idea up in #go-nuts.
My ideal scenario would be to check if copyChan is writeable, pop job from the
queue and shove it down handleFile. This way jobs would stay in the queue while
they cannot be handled, meaning that the `Bump` could bring your file up higher.
2014-12-01 19:23:06 +00:00
|
|
|
|
2014-12-30 08:35:21 +00:00
|
|
|
type jobQueue struct {
|
2014-12-30 08:31:34 +00:00
|
|
|
progress []string
|
2015-04-25 05:13:53 +00:00
|
|
|
queued []jobQueueEntry
|
2014-12-30 08:07:58 +00:00
|
|
|
mut sync.Mutex
|
Add job queue (fixes #629)
Request to terminate currently ongoing downloads and jump to the bumped file
incoming in 3, 2, 1.
Also, has a slightly strange effect where we pop a job off the queue, but
the copyChannel is still busy and blocks, though it gets moved to the
progress slice in the jobqueue, and looks like it's in progress which it isn't
as it's waiting to be picked up from the copyChan.
As a result, the progress emitter doesn't register on the task, and hence the file
doesn't have a progress bar, but cannot be replaced by a bump.
I guess I can fix progress bar issue by moving the progressEmiter.Register just
before passing the file to the copyChan, but then we are back to the initial
problem of a file with a progress bar, but no progress happening as it's stuck
on write to copyChan
I checked if there is a way to check for channel writeability (before popping)
but got struck by lightning just for bringing the idea up in #go-nuts.
My ideal scenario would be to check if copyChan is writeable, pop job from the
queue and shove it down handleFile. This way jobs would stay in the queue while
they cannot be handled, meaning that the `Bump` could bring your file up higher.
2014-12-01 19:23:06 +00:00
|
|
|
}
|
|
|
|
|
2015-04-25 05:13:53 +00:00
|
|
|
type jobQueueEntry struct {
|
|
|
|
name string
|
|
|
|
size int64
|
2016-08-06 13:05:59 +00:00
|
|
|
modified time.Time
|
2015-04-25 05:13:53 +00:00
|
|
|
}
|
|
|
|
|
2014-12-30 08:35:21 +00:00
|
|
|
func newJobQueue() *jobQueue {
|
2015-04-22 22:54:31 +00:00
|
|
|
return &jobQueue{
|
|
|
|
mut: sync.NewMutex(),
|
|
|
|
}
|
Add job queue (fixes #629)
Request to terminate currently ongoing downloads and jump to the bumped file
incoming in 3, 2, 1.
Also, has a slightly strange effect where we pop a job off the queue, but
the copyChannel is still busy and blocks, though it gets moved to the
progress slice in the jobqueue, and looks like it's in progress which it isn't
as it's waiting to be picked up from the copyChan.
As a result, the progress emitter doesn't register on the task, and hence the file
doesn't have a progress bar, but cannot be replaced by a bump.
I guess I can fix progress bar issue by moving the progressEmiter.Register just
before passing the file to the copyChan, but then we are back to the initial
problem of a file with a progress bar, but no progress happening as it's stuck
on write to copyChan
I checked if there is a way to check for channel writeability (before popping)
but got struck by lightning just for bringing the idea up in #go-nuts.
My ideal scenario would be to check if copyChan is writeable, pop job from the
queue and shove it down handleFile. This way jobs would stay in the queue while
they cannot be handled, meaning that the `Bump` could bring your file up higher.
2014-12-01 19:23:06 +00:00
|
|
|
}
|
|
|
|
|
2016-08-06 13:05:59 +00:00
|
|
|
func (q *jobQueue) Push(file string, size int64, modified time.Time) {
|
Add job queue (fixes #629)
Request to terminate currently ongoing downloads and jump to the bumped file
incoming in 3, 2, 1.
Also, has a slightly strange effect where we pop a job off the queue, but
the copyChannel is still busy and blocks, though it gets moved to the
progress slice in the jobqueue, and looks like it's in progress which it isn't
as it's waiting to be picked up from the copyChan.
As a result, the progress emitter doesn't register on the task, and hence the file
doesn't have a progress bar, but cannot be replaced by a bump.
I guess I can fix progress bar issue by moving the progressEmiter.Register just
before passing the file to the copyChan, but then we are back to the initial
problem of a file with a progress bar, but no progress happening as it's stuck
on write to copyChan
I checked if there is a way to check for channel writeability (before popping)
but got struck by lightning just for bringing the idea up in #go-nuts.
My ideal scenario would be to check if copyChan is writeable, pop job from the
queue and shove it down handleFile. This way jobs would stay in the queue while
they cannot be handled, meaning that the `Bump` could bring your file up higher.
2014-12-01 19:23:06 +00:00
|
|
|
q.mut.Lock()
|
2015-04-25 05:13:53 +00:00
|
|
|
q.queued = append(q.queued, jobQueueEntry{file, size, modified})
|
2014-12-30 08:07:58 +00:00
|
|
|
q.mut.Unlock()
|
Add job queue (fixes #629)
Request to terminate currently ongoing downloads and jump to the bumped file
incoming in 3, 2, 1.
Also, has a slightly strange effect where we pop a job off the queue, but
the copyChannel is still busy and blocks, though it gets moved to the
progress slice in the jobqueue, and looks like it's in progress which it isn't
as it's waiting to be picked up from the copyChan.
As a result, the progress emitter doesn't register on the task, and hence the file
doesn't have a progress bar, but cannot be replaced by a bump.
I guess I can fix progress bar issue by moving the progressEmiter.Register just
before passing the file to the copyChan, but then we are back to the initial
problem of a file with a progress bar, but no progress happening as it's stuck
on write to copyChan
I checked if there is a way to check for channel writeability (before popping)
but got struck by lightning just for bringing the idea up in #go-nuts.
My ideal scenario would be to check if copyChan is writeable, pop job from the
queue and shove it down handleFile. This way jobs would stay in the queue while
they cannot be handled, meaning that the `Bump` could bring your file up higher.
2014-12-01 19:23:06 +00:00
|
|
|
}
|
|
|
|
|
2014-12-30 08:35:21 +00:00
|
|
|
func (q *jobQueue) Pop() (string, bool) {
|
Add job queue (fixes #629)
Request to terminate currently ongoing downloads and jump to the bumped file
incoming in 3, 2, 1.
Also, has a slightly strange effect where we pop a job off the queue, but
the copyChannel is still busy and blocks, though it gets moved to the
progress slice in the jobqueue, and looks like it's in progress which it isn't
as it's waiting to be picked up from the copyChan.
As a result, the progress emitter doesn't register on the task, and hence the file
doesn't have a progress bar, but cannot be replaced by a bump.
I guess I can fix progress bar issue by moving the progressEmiter.Register just
before passing the file to the copyChan, but then we are back to the initial
problem of a file with a progress bar, but no progress happening as it's stuck
on write to copyChan
I checked if there is a way to check for channel writeability (before popping)
but got struck by lightning just for bringing the idea up in #go-nuts.
My ideal scenario would be to check if copyChan is writeable, pop job from the
queue and shove it down handleFile. This way jobs would stay in the queue while
they cannot be handled, meaning that the `Bump` could bring your file up higher.
2014-12-01 19:23:06 +00:00
|
|
|
q.mut.Lock()
|
|
|
|
defer q.mut.Unlock()
|
|
|
|
|
2014-12-30 08:07:58 +00:00
|
|
|
if len(q.queued) == 0 {
|
2014-12-30 08:31:34 +00:00
|
|
|
return "", false
|
Add job queue (fixes #629)
Request to terminate currently ongoing downloads and jump to the bumped file
incoming in 3, 2, 1.
Also, has a slightly strange effect where we pop a job off the queue, but
the copyChannel is still busy and blocks, though it gets moved to the
progress slice in the jobqueue, and looks like it's in progress which it isn't
as it's waiting to be picked up from the copyChan.
As a result, the progress emitter doesn't register on the task, and hence the file
doesn't have a progress bar, but cannot be replaced by a bump.
I guess I can fix progress bar issue by moving the progressEmiter.Register just
before passing the file to the copyChan, but then we are back to the initial
problem of a file with a progress bar, but no progress happening as it's stuck
on write to copyChan
I checked if there is a way to check for channel writeability (before popping)
but got struck by lightning just for bringing the idea up in #go-nuts.
My ideal scenario would be to check if copyChan is writeable, pop job from the
queue and shove it down handleFile. This way jobs would stay in the queue while
they cannot be handled, meaning that the `Bump` could bring your file up higher.
2014-12-01 19:23:06 +00:00
|
|
|
}
|
|
|
|
|
2015-04-25 05:13:53 +00:00
|
|
|
f := q.queued[0].name
|
2014-12-30 08:07:58 +00:00
|
|
|
q.queued = q.queued[1:]
|
Add job queue (fixes #629)
Request to terminate currently ongoing downloads and jump to the bumped file
incoming in 3, 2, 1.
Also, has a slightly strange effect where we pop a job off the queue, but
the copyChannel is still busy and blocks, though it gets moved to the
progress slice in the jobqueue, and looks like it's in progress which it isn't
as it's waiting to be picked up from the copyChan.
As a result, the progress emitter doesn't register on the task, and hence the file
doesn't have a progress bar, but cannot be replaced by a bump.
I guess I can fix progress bar issue by moving the progressEmiter.Register just
before passing the file to the copyChan, but then we are back to the initial
problem of a file with a progress bar, but no progress happening as it's stuck
on write to copyChan
I checked if there is a way to check for channel writeability (before popping)
but got struck by lightning just for bringing the idea up in #go-nuts.
My ideal scenario would be to check if copyChan is writeable, pop job from the
queue and shove it down handleFile. This way jobs would stay in the queue while
they cannot be handled, meaning that the `Bump` could bring your file up higher.
2014-12-01 19:23:06 +00:00
|
|
|
q.progress = append(q.progress, f)
|
|
|
|
|
2014-12-30 08:31:34 +00:00
|
|
|
return f, true
|
Add job queue (fixes #629)
Request to terminate currently ongoing downloads and jump to the bumped file
incoming in 3, 2, 1.
Also, has a slightly strange effect where we pop a job off the queue, but
the copyChannel is still busy and blocks, though it gets moved to the
progress slice in the jobqueue, and looks like it's in progress which it isn't
as it's waiting to be picked up from the copyChan.
As a result, the progress emitter doesn't register on the task, and hence the file
doesn't have a progress bar, but cannot be replaced by a bump.
I guess I can fix progress bar issue by moving the progressEmiter.Register just
before passing the file to the copyChan, but then we are back to the initial
problem of a file with a progress bar, but no progress happening as it's stuck
on write to copyChan
I checked if there is a way to check for channel writeability (before popping)
but got struck by lightning just for bringing the idea up in #go-nuts.
My ideal scenario would be to check if copyChan is writeable, pop job from the
queue and shove it down handleFile. This way jobs would stay in the queue while
they cannot be handled, meaning that the `Bump` could bring your file up higher.
2014-12-01 19:23:06 +00:00
|
|
|
}
|
|
|
|
|
2014-12-30 08:35:21 +00:00
|
|
|
func (q *jobQueue) BringToFront(filename string) {
|
Add job queue (fixes #629)
Request to terminate currently ongoing downloads and jump to the bumped file
incoming in 3, 2, 1.
Also, has a slightly strange effect where we pop a job off the queue, but
the copyChannel is still busy and blocks, though it gets moved to the
progress slice in the jobqueue, and looks like it's in progress which it isn't
as it's waiting to be picked up from the copyChan.
As a result, the progress emitter doesn't register on the task, and hence the file
doesn't have a progress bar, but cannot be replaced by a bump.
I guess I can fix progress bar issue by moving the progressEmiter.Register just
before passing the file to the copyChan, but then we are back to the initial
problem of a file with a progress bar, but no progress happening as it's stuck
on write to copyChan
I checked if there is a way to check for channel writeability (before popping)
but got struck by lightning just for bringing the idea up in #go-nuts.
My ideal scenario would be to check if copyChan is writeable, pop job from the
queue and shove it down handleFile. This way jobs would stay in the queue while
they cannot be handled, meaning that the `Bump` could bring your file up higher.
2014-12-01 19:23:06 +00:00
|
|
|
q.mut.Lock()
|
|
|
|
defer q.mut.Unlock()
|
|
|
|
|
2015-01-02 14:45:59 +00:00
|
|
|
for i, cur := range q.queued {
|
2015-04-25 05:13:53 +00:00
|
|
|
if cur.name == filename {
|
2015-01-02 14:45:59 +00:00
|
|
|
if i > 0 {
|
|
|
|
// Shift the elements before the selected element one step to
|
|
|
|
// the right, overwriting the selected element
|
|
|
|
copy(q.queued[1:i+1], q.queued[0:])
|
|
|
|
// Put the selected element at the front
|
|
|
|
q.queued[0] = cur
|
|
|
|
}
|
2014-12-30 08:07:58 +00:00
|
|
|
return
|
|
|
|
}
|
Add job queue (fixes #629)
Request to terminate currently ongoing downloads and jump to the bumped file
incoming in 3, 2, 1.
Also, has a slightly strange effect where we pop a job off the queue, but
the copyChannel is still busy and blocks, though it gets moved to the
progress slice in the jobqueue, and looks like it's in progress which it isn't
as it's waiting to be picked up from the copyChan.
As a result, the progress emitter doesn't register on the task, and hence the file
doesn't have a progress bar, but cannot be replaced by a bump.
I guess I can fix progress bar issue by moving the progressEmiter.Register just
before passing the file to the copyChan, but then we are back to the initial
problem of a file with a progress bar, but no progress happening as it's stuck
on write to copyChan
I checked if there is a way to check for channel writeability (before popping)
but got struck by lightning just for bringing the idea up in #go-nuts.
My ideal scenario would be to check if copyChan is writeable, pop job from the
queue and shove it down handleFile. This way jobs would stay in the queue while
they cannot be handled, meaning that the `Bump` could bring your file up higher.
2014-12-01 19:23:06 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-12-30 08:35:21 +00:00
|
|
|
func (q *jobQueue) Done(file string) {
|
Add job queue (fixes #629)
Request to terminate currently ongoing downloads and jump to the bumped file
incoming in 3, 2, 1.
Also, has a slightly strange effect where we pop a job off the queue, but
the copyChannel is still busy and blocks, though it gets moved to the
progress slice in the jobqueue, and looks like it's in progress which it isn't
as it's waiting to be picked up from the copyChan.
As a result, the progress emitter doesn't register on the task, and hence the file
doesn't have a progress bar, but cannot be replaced by a bump.
I guess I can fix progress bar issue by moving the progressEmiter.Register just
before passing the file to the copyChan, but then we are back to the initial
problem of a file with a progress bar, but no progress happening as it's stuck
on write to copyChan
I checked if there is a way to check for channel writeability (before popping)
but got struck by lightning just for bringing the idea up in #go-nuts.
My ideal scenario would be to check if copyChan is writeable, pop job from the
queue and shove it down handleFile. This way jobs would stay in the queue while
they cannot be handled, meaning that the `Bump` could bring your file up higher.
2014-12-01 19:23:06 +00:00
|
|
|
q.mut.Lock()
|
|
|
|
defer q.mut.Unlock()
|
|
|
|
|
|
|
|
for i := range q.progress {
|
2014-12-30 08:31:34 +00:00
|
|
|
if q.progress[i] == file {
|
Add job queue (fixes #629)
Request to terminate currently ongoing downloads and jump to the bumped file
incoming in 3, 2, 1.
Also, has a slightly strange effect where we pop a job off the queue, but
the copyChannel is still busy and blocks, though it gets moved to the
progress slice in the jobqueue, and looks like it's in progress which it isn't
as it's waiting to be picked up from the copyChan.
As a result, the progress emitter doesn't register on the task, and hence the file
doesn't have a progress bar, but cannot be replaced by a bump.
I guess I can fix progress bar issue by moving the progressEmiter.Register just
before passing the file to the copyChan, but then we are back to the initial
problem of a file with a progress bar, but no progress happening as it's stuck
on write to copyChan
I checked if there is a way to check for channel writeability (before popping)
but got struck by lightning just for bringing the idea up in #go-nuts.
My ideal scenario would be to check if copyChan is writeable, pop job from the
queue and shove it down handleFile. This way jobs would stay in the queue while
they cannot be handled, meaning that the `Bump` could bring your file up higher.
2014-12-01 19:23:06 +00:00
|
|
|
copy(q.progress[i:], q.progress[i+1:])
|
|
|
|
q.progress = q.progress[:len(q.progress)-1]
|
|
|
|
return
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-06-27 18:25:38 +00:00
|
|
|
// Jobs returns a paginated list of file currently being pulled and files queued
|
|
|
|
// to be pulled. It also returns how many items were skipped.
|
|
|
|
func (q *jobQueue) Jobs(page, perpage int) ([]string, []string, int) {
|
Add job queue (fixes #629)
Request to terminate currently ongoing downloads and jump to the bumped file
incoming in 3, 2, 1.
Also, has a slightly strange effect where we pop a job off the queue, but
the copyChannel is still busy and blocks, though it gets moved to the
progress slice in the jobqueue, and looks like it's in progress which it isn't
as it's waiting to be picked up from the copyChan.
As a result, the progress emitter doesn't register on the task, and hence the file
doesn't have a progress bar, but cannot be replaced by a bump.
I guess I can fix progress bar issue by moving the progressEmiter.Register just
before passing the file to the copyChan, but then we are back to the initial
problem of a file with a progress bar, but no progress happening as it's stuck
on write to copyChan
I checked if there is a way to check for channel writeability (before popping)
but got struck by lightning just for bringing the idea up in #go-nuts.
My ideal scenario would be to check if copyChan is writeable, pop job from the
queue and shove it down handleFile. This way jobs would stay in the queue while
they cannot be handled, meaning that the `Bump` could bring your file up higher.
2014-12-01 19:23:06 +00:00
|
|
|
q.mut.Lock()
|
|
|
|
defer q.mut.Unlock()
|
|
|
|
|
2019-06-27 18:25:38 +00:00
|
|
|
toSkip := (page - 1) * perpage
|
|
|
|
plen := len(q.progress)
|
|
|
|
qlen := len(q.queued)
|
Add job queue (fixes #629)
Request to terminate currently ongoing downloads and jump to the bumped file
incoming in 3, 2, 1.
Also, has a slightly strange effect where we pop a job off the queue, but
the copyChannel is still busy and blocks, though it gets moved to the
progress slice in the jobqueue, and looks like it's in progress which it isn't
as it's waiting to be picked up from the copyChan.
As a result, the progress emitter doesn't register on the task, and hence the file
doesn't have a progress bar, but cannot be replaced by a bump.
I guess I can fix progress bar issue by moving the progressEmiter.Register just
before passing the file to the copyChan, but then we are back to the initial
problem of a file with a progress bar, but no progress happening as it's stuck
on write to copyChan
I checked if there is a way to check for channel writeability (before popping)
but got struck by lightning just for bringing the idea up in #go-nuts.
My ideal scenario would be to check if copyChan is writeable, pop job from the
queue and shove it down handleFile. This way jobs would stay in the queue while
they cannot be handled, meaning that the `Bump` could bring your file up higher.
2014-12-01 19:23:06 +00:00
|
|
|
|
2019-06-27 18:25:38 +00:00
|
|
|
if tot := plen + qlen; tot <= toSkip {
|
|
|
|
return nil, nil, tot
|
2015-04-25 05:13:53 +00:00
|
|
|
}
|
Add job queue (fixes #629)
Request to terminate currently ongoing downloads and jump to the bumped file
incoming in 3, 2, 1.
Also, has a slightly strange effect where we pop a job off the queue, but
the copyChannel is still busy and blocks, though it gets moved to the
progress slice in the jobqueue, and looks like it's in progress which it isn't
as it's waiting to be picked up from the copyChan.
As a result, the progress emitter doesn't register on the task, and hence the file
doesn't have a progress bar, but cannot be replaced by a bump.
I guess I can fix progress bar issue by moving the progressEmiter.Register just
before passing the file to the copyChan, but then we are back to the initial
problem of a file with a progress bar, but no progress happening as it's stuck
on write to copyChan
I checked if there is a way to check for channel writeability (before popping)
but got struck by lightning just for bringing the idea up in #go-nuts.
My ideal scenario would be to check if copyChan is writeable, pop job from the
queue and shove it down handleFile. This way jobs would stay in the queue while
they cannot be handled, meaning that the `Bump` could bring your file up higher.
2014-12-01 19:23:06 +00:00
|
|
|
|
2019-06-27 18:25:38 +00:00
|
|
|
if plen >= toSkip+perpage {
|
|
|
|
progress := make([]string, perpage)
|
|
|
|
copy(progress, q.progress[toSkip:toSkip+perpage])
|
|
|
|
return progress, nil, toSkip
|
|
|
|
}
|
|
|
|
|
|
|
|
var progress []string
|
|
|
|
if plen > toSkip {
|
|
|
|
progress = make([]string, plen-toSkip)
|
|
|
|
copy(progress, q.progress[toSkip:plen])
|
|
|
|
toSkip = 0
|
|
|
|
} else {
|
|
|
|
toSkip -= plen
|
|
|
|
}
|
|
|
|
|
|
|
|
var queued []string
|
|
|
|
if qlen-toSkip < perpage-len(progress) {
|
|
|
|
queued = make([]string, qlen-toSkip)
|
|
|
|
} else {
|
|
|
|
queued = make([]string, perpage-len(progress))
|
|
|
|
}
|
|
|
|
for i := range queued {
|
|
|
|
queued[i] = q.queued[i+toSkip].name
|
|
|
|
}
|
|
|
|
|
|
|
|
return progress, queued, (page - 1) * perpage
|
Add job queue (fixes #629)
Request to terminate currently ongoing downloads and jump to the bumped file
incoming in 3, 2, 1.
Also, has a slightly strange effect where we pop a job off the queue, but
the copyChannel is still busy and blocks, though it gets moved to the
progress slice in the jobqueue, and looks like it's in progress which it isn't
as it's waiting to be picked up from the copyChan.
As a result, the progress emitter doesn't register on the task, and hence the file
doesn't have a progress bar, but cannot be replaced by a bump.
I guess I can fix progress bar issue by moving the progressEmiter.Register just
before passing the file to the copyChan, but then we are back to the initial
problem of a file with a progress bar, but no progress happening as it's stuck
on write to copyChan
I checked if there is a way to check for channel writeability (before popping)
but got struck by lightning just for bringing the idea up in #go-nuts.
My ideal scenario would be to check if copyChan is writeable, pop job from the
queue and shove it down handleFile. This way jobs would stay in the queue while
they cannot be handled, meaning that the `Bump` could bring your file up higher.
2014-12-01 19:23:06 +00:00
|
|
|
}
|
2015-04-25 05:13:53 +00:00
|
|
|
|
|
|
|
func (q *jobQueue) Shuffle() {
|
|
|
|
q.mut.Lock()
|
|
|
|
defer q.mut.Unlock()
|
|
|
|
|
2019-05-29 07:56:40 +00:00
|
|
|
rand.Shuffle(q.queued)
|
2015-04-25 05:13:53 +00:00
|
|
|
}
|
|
|
|
|
2019-03-27 19:19:35 +00:00
|
|
|
func (q *jobQueue) Reset() {
|
|
|
|
q.mut.Lock()
|
|
|
|
defer q.mut.Unlock()
|
|
|
|
q.progress = nil
|
|
|
|
q.queued = nil
|
|
|
|
}
|
|
|
|
|
2015-10-20 06:51:14 +00:00
|
|
|
func (q *jobQueue) lenQueued() int {
|
|
|
|
q.mut.Lock()
|
|
|
|
defer q.mut.Unlock()
|
|
|
|
return len(q.queued)
|
|
|
|
}
|
|
|
|
|
|
|
|
func (q *jobQueue) lenProgress() int {
|
|
|
|
q.mut.Lock()
|
|
|
|
defer q.mut.Unlock()
|
|
|
|
return len(q.progress)
|
|
|
|
}
|
|
|
|
|
2015-04-25 05:13:53 +00:00
|
|
|
func (q *jobQueue) SortSmallestFirst() {
|
|
|
|
q.mut.Lock()
|
|
|
|
defer q.mut.Unlock()
|
|
|
|
|
|
|
|
sort.Sort(smallestFirst(q.queued))
|
|
|
|
}
|
|
|
|
|
|
|
|
func (q *jobQueue) SortLargestFirst() {
|
|
|
|
q.mut.Lock()
|
|
|
|
defer q.mut.Unlock()
|
|
|
|
|
|
|
|
sort.Sort(sort.Reverse(smallestFirst(q.queued)))
|
|
|
|
}
|
|
|
|
|
|
|
|
func (q *jobQueue) SortOldestFirst() {
|
|
|
|
q.mut.Lock()
|
|
|
|
defer q.mut.Unlock()
|
|
|
|
|
|
|
|
sort.Sort(oldestFirst(q.queued))
|
|
|
|
}
|
|
|
|
|
|
|
|
func (q *jobQueue) SortNewestFirst() {
|
|
|
|
q.mut.Lock()
|
|
|
|
defer q.mut.Unlock()
|
|
|
|
|
|
|
|
sort.Sort(sort.Reverse(oldestFirst(q.queued)))
|
|
|
|
}
|
|
|
|
|
|
|
|
// The usual sort.Interface boilerplate
|
|
|
|
|
|
|
|
type smallestFirst []jobQueueEntry
|
|
|
|
|
|
|
|
func (q smallestFirst) Len() int { return len(q) }
|
|
|
|
func (q smallestFirst) Less(a, b int) bool { return q[a].size < q[b].size }
|
|
|
|
func (q smallestFirst) Swap(a, b int) { q[a], q[b] = q[b], q[a] }
|
|
|
|
|
|
|
|
type oldestFirst []jobQueueEntry
|
|
|
|
|
|
|
|
func (q oldestFirst) Len() int { return len(q) }
|
2016-08-06 13:05:59 +00:00
|
|
|
func (q oldestFirst) Less(a, b int) bool { return q[a].modified.Before(q[b].modified) }
|
2015-04-25 05:13:53 +00:00
|
|
|
func (q oldestFirst) Swap(a, b int) { q[a], q[b] = q[b], q[a] }
|