Non-blocking audio.save()

[GoogleCodeExporter]

Would it be possible to have a non-blocking save() operation ?
For example, I would like to have an asynchronous call like this :
audio=ID3(....) or OggVorbis(....) or FLAC(....) ,etc.
#do some stuff, add/remove tags, etc...
finish=audio.save() # non blocking

That way I could implement idle callbacks properly  for my rhythmbox plugin > 
http://live.gnome.org/RhythmboxPlugins/WritingGuide#Using_idle_callbacks_for_rep
eated_tasks

Original issue reported on code.google.com by vysse...@gmail.com on 17 Feb 2011 at 9:16

[GoogleCodeExporter]

(I swear I wrote a response to this already, weeks ago? Did it get eaten?)

Non-blocking save is very dangerous. It means you could, for example, exit the 
program with the data only half written. It also doesn't make a lot of sense, 
unless you also have some per-frame call for incremental writes. In the common 
and ideal case, Mutagen consists of only a handful of system calls - map, move, 
some writes, flush, close.[0] Of those, only move and flush will likely take 
appreciable time. So there's not a lot of useful points to actually yield 
control in a cooperative system.

On the other hand, a preemptive system will work as best as any preemptive 
system in Python can. Just spin off a thread that handles a queue of writes.

Mutagen is threadsafe on Unix - multiple writes to different files don't 
interfere with each other, and multiple writes to the same file guarantees 
exactly one of them makes it through consistently on any filesystem that 
supports POSIX locks. (Any issues in this will be considered high-priority 
bugs.) I'm less sure about Windows, but I think the exclusive-by-default writes 
will result in the same thing.

So, WontFix. The goal of not pausing the UI during writes is laudable, but I 
think it is already as feasible as it will get - and certainly more feasible 
than I ever bothered to implement in Quod Libet.

[0] Mutagen does not call fsync, an issue I've been of two minds about forever. 
Performance is the obvious reason why not; another is that unless we commit to 
real atomic writes, it's plugging one hole out of a dozen, which is not all 
that useful. And committing to real atomic writes means even worse performance 
problems, and the concern that someone retagging a multi-hundred-megabyte file 
might not have that much hard drive space remaining to write out the copy.

Original comment by joe.wreschnig@gmail.com on 2 Mar 2011 at 11:23

• Changed state: WontFix

[GoogleCodeExporter]

Thx for the explanation ;)
I use idle callback now 
(http://live.gnome.org/RhythmboxPlugins/WritingGuide#Using_asynchronous_IO)

Original comment by vysse...@gmail.com on 17 Mar 2011 at 8:53