Almost insignificant bug: multiple connection launch order

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

  1. 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
  2. create a thread pool of four launchers
  3. 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:

  1. create a thread pool of four (or more?) launchers, depending on eBay API rules and memory for guidance on how many
  2. queue the collection of pending listings
  3. 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?

1 Like

Congrats on correctly figuring out how the multi-threaded listing upload works in GarageSale.

It’s not the most efficient when it comes to overall end time, but it was relatively easy and elegant to implement. (I checked the code and it only added 3 extra lines of code compared to the single threaded solution).

I can see how a version which schedules more efficiently would be an improvement when listing a lot of listings and will create a ticket for your request.

1 Like

In my experience in other languages, it will depend a lot on how reliable and well-supported the async libraries are in the language and app framework you’re using. Long ago I made a huge evolutionary algorithms thing run 100x faster using a new thread pool library… and then discovered that it didn’t work on any of my colleagues’ machines.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.