Multithreaded Version In Sight?

Hi,

do you have plans to modify Mp3tag so it can take advantage of multithreaded CPUs and OSs out there?

I think I'd enjoy if Mp3tag could save in the background, and allow me to continue working while it's saving.

I don't know how much code that represents, but in my opinion, it's probably not much... I mean, it's probably just to fork the save function, and add a function that doesn't allow you to save before the current save operation has completed, and maybe a bit of error handling, and maybe a configuration option to either enable background saves, or not.

?

1 Like

If you see the current implementation as the closest thing you can get to some kind of transaction mechanism without an actual database handler in the background, I see the current state as the only way to guarantee data integrity.
As e.g. the sequence of actions may be crucial for a successful execution it would be hazardous to have one group of actions run faster than the other - which I think is implied by the multi-thread option.
Just my thoughts on the topic.

What?

What "what"?
Any action you run saves data, not just the "Save" function in the toolbar or the keyboard shortcut Ctrl-S. So this would mean that more or less every function would run in the background.
Running in the background would make it impossible to cancel the current execution that implies saves.
If you save data in the background and it would be possible to e.g. set a filter in the meantime, you cannot be sure that the list of files that is displayed at the time of setting the filter is actually the complete list as the saving in the background coluld lead to further files that either match or do not match the filter criteria.
The same applies to exports: you cannot be sure that the sorted result is the final one, while saving is going on in the background.