View Single Post
Old 06-22-2011, 04:42 PM   #24
chaley
Grand Sorcerer
chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.
 
Posts: 12,469
Karma: 8025600
Join Date: Jan 2010
Location: Notts, England
Device: Kobo Libra 2
Quote:
Originally Posted by kovidgoyal View Post
All in all, there doesn't seem to be anyway to do this. I though of using tcp/ip sockets, but then there will be problems on windows with antivirus programs blocking the creation of the sockets.
Threads & sockets don't work?
Quote:
I dont really see any way out for this except to do what calibre does in this kind of situation, which is first run in process, copy out the data that is being worked on, and then launch a worker process that works on the data and returns the results via the filesystem. This does have performance implications, but for the vast majority of ebook files, the performance hit should be very small.
If the problem is not producer-consumer, then you are probably right. However, if it is, then I don't understand why subprocesses can't be given pipes.
Quote:
That leaves launching external editors on data. At the moment, the only thing I can see is monitoring the temp file for changes. We can add API to have the temp file created outside the normal calibre temp dir, so that if the user leaves the external editor running when quitting calibre, it will not affect temp file cleanup for the other temp files.
You are probably correct. By definition, we have no control over what the external program does, so we must work at its level of abstraction, which is the file.

It might be possible to avoid polling loops by using pessimistic locking and letting the user to indicate that s/he is finished. This is similar to what kiwidude didn't want, but might be acceptable because it is non-blocking. In effect, we provide an 'export', locking the book object for update. Whatever application does its thing. When finished, run something that imports the results and breaks the lock.

We could choose to go optimistic and not lock anything, with the problem that if the object is updated twice, one of the updates loses, but this also requires the user to indicate that s/he is finished. Optimistic locking works most of the time, but tends to fail spectacularly when it fails.

My thought is that there might be a local 'cache' of the library outside of the temp directory. Exports go there and imports come from there. Both export and import are explicit commands.

Detecting concurrent update isn't hard. The export would have a timestamp/signature. If at import time the object has a different signature, a choice would need to be made -- which wins.

This is fairly classic multi-user DB stuff. Consider airline seat reservation. I see a map, pick a seat, and say 'go', only to be told that someone else has already reserved that seat. Same thing with purchases of items with limited stock.
chaley is offline   Reply With Quote