I've noticed for quite some time now that if you have a list of background jobs (queued copy/move jobs) and one is actively running, manually starting another second job from that list will set the queue to always start 2 jobs at a time from then on instead of 1 as it's supposed to.
I expected that if I start another job while one is already running, when the other job finishes it will keep running only one job at a time. But if I have one job running and I manually start 2 more from the list, for example, XYplorer will keep starting 3 jobs in parallel from then on instead of just 1, until the list is cleared.
So basically if I manually start a job from the background list, when that job finishes XYplorer should keep running only 1 job at a time.
Starting a background job while another is running breaks the 1-job-only queue functionality
-
- Site Admin
- Posts: 60585
- Joined: 22 May 2004 16:48
- Location: Win8.1 @100%, Win10 @100%
- Contact:
Re: Starting a background job while another is running breaks the 1-job-only queue functionality
Well it's built that way. I don't think this is new. If you start a job manually while a queue is running, you are effectively starting a new queue that will run in parallel with the existing queue(s).
FAQ | XY News RSS | XY Twitter
Re: Starting a background job while another is running breaks the 1-job-only queue functionality
I don't think that sounds correct. (2 queues would mean 2 different lists to be done.)
I think the start should mean to take one job out of the queue and execute it immediate.
(Or to move it to the top of the queue to not run async - but this would not be named start, but e.g. prefer.)
I think the start should mean to take one job out of the queue and execute it immediate.
(Or to move it to the top of the queue to not run async - but this would not be named start, but e.g. prefer.)
Win11 Pro 223H2 Gerrman
-
- Site Admin
- Posts: 60585
- Joined: 22 May 2004 16:48
- Location: Win8.1 @100%, Win10 @100%
- Contact:
Re: Starting a background job while another is running breaks the 1-job-only queue functionality
Is there a problem? It works like this for many years, I didn't touch that code for many years. I need a good reason to change a well-oiled system.
FAQ | XY News RSS | XY Twitter
Re: Starting a background job while another is running breaks the 1-job-only queue functionality
Sorry for slow reaction,
and no - it's not a real problem for me. (Usually not backgrounded copying )
But I think what the command "Start (a job)" says and what it does is not consistant.
In general I'm with the description of the opening topic.
In details:
- if I would want a second (parallel) execution instance (for the one queue - I think it's like that) I would request a second exec-instance.
- if I have reason just to start one job immediate, I would just start especially this one (as the cmd says).
We know: usually copy speed depends on the speed of the device - so parallel copies on the same device gain no speed, but is bad on old HDD ("head-positioning").
So adding more exec-instances should *only* be done on an explicit request (if really needed), while request to start / prefer a special job should only do this - and not start 1 more parallel exec-instance.
I think:
- not all us BG copy
- those using it might not often start a job on the queue
- those doing it might not notice that then 2 exec instances are running
- and those noticing it might not think of disadvantages.
What to do? I don't know how much work it is - especially to make it consistant!
(OK: change the command to "Start job and add 1 more exec instances" )
and no - it's not a real problem for me. (Usually not backgrounded copying )
But I think what the command "Start (a job)" says and what it does is not consistant.
In general I'm with the description of the opening topic.
In details:
- if I would want a second (parallel) execution instance (for the one queue - I think it's like that) I would request a second exec-instance.
- if I have reason just to start one job immediate, I would just start especially this one (as the cmd says).
We know: usually copy speed depends on the speed of the device - so parallel copies on the same device gain no speed, but is bad on old HDD ("head-positioning").
So adding more exec-instances should *only* be done on an explicit request (if really needed), while request to start / prefer a special job should only do this - and not start 1 more parallel exec-instance.
I think:
- not all us BG copy
- those using it might not often start a job on the queue
- those doing it might not notice that then 2 exec instances are running
- and those noticing it might not think of disadvantages.
What to do? I don't know how much work it is - especially to make it consistant!
(OK: change the command to "Start job and add 1 more exec instances" )
Win11 Pro 223H2 Gerrman
-
- Site Admin
- Posts: 60585
- Joined: 22 May 2004 16:48
- Location: Win8.1 @100%, Win10 @100%
- Contact:
Re: Starting a background job while another is running breaks the 1-job-only queue functionality
Agreed. Should work as expected in the next beta.
FAQ | XY News RSS | XY Twitter
Re: Starting a background job while another is running breaks the 1-job-only queue functionality
I hadn't expected this
But fine:
I hope woofy31 will be glad, too.
But fine:
I hope woofy31 will be glad, too.
Win11 Pro 223H2 Gerrman
Re: Starting a background job while another is running breaks the 1-job-only queue functionality
I would've been happy, but it's been months since I posted this feature request, and after many betas later it still does the same thing.
Let me explain the BIG problem this introduces: I made a long list of background copy operations between several external hard disks, then I made the mistake of drag-n-dropping a file between panes and the HORROR happened: a second parallel task from that background list started executing, putting strain on my extHDDs - later I was forced to do another drag-n-drop so a 3rd background task started from that same list, rendering my extHDDs super slow, so I had to use Windows Explorer to do more drag-drop operations to avoid XYplorer starting too many parallel background tasks, while also pausing some background operations because XYplorer decided to force my extHDDs with multiple parallel operations from that same background list.
I hope you get the idea: a simple drag-n-drop while a background operation runs => XYplorer starts executing more parallel operations from the same list of background tasks => all involved HDDs become super slow since they are used at the same time.