Fair warning; I’m using the term “bug” here in the sense my friend Ron Jeffries taught me: “Software behaves in a way that differs from user expectations.”
I have noticed that when I have several hundred listings open in Launch Control, and select “Use multiple connections”, the behavior I see seems to be
- divide the number of listings to launch by 4, so that the first group is
[1,5,9,13,...]
, the second is[2,6,10,14,...]
, and so on - create a thread pool of four launchers
- asynchronously run those four launchers on the array of listings they have been passed, in sequential order
This is… OK? It does have the side-effect that the slowest thread controls the endpoint of the launch.
I would think, though, that it might be maybe “more OK” if the behavior were:
- create a thread pool of four (or more?) launchers, depending on eBay API rules and memory for guidance on how many
- queue the collection of pending listings
- let the completed response of each launcher include removing the next unlaunched listing from the queue
That is, do the work actually asynchronously, but in order (ish)?
I mean this is all moot, since you specifically say “launch in random order” in the tooltip, but I do sometimes wonder if maybe this same thread-pool-and-work-queue design pattern could help with, say, the slow responses of cancel-and-relaunch systems, and maybe the sync problems folks report?
I’m just guessing what you’re doing on the developer side, of course. But maybe it might help all these things?