Editing two epubs at the same time

[jwes]

I have two epubs open in two instances of Sigil. I save one, which takes a significant amount of time. The other instance of Sigil is unresponsive until the first one is finished saving. Is this expected behavior?

[DiapDealer]

I've never had an epub take a "significant" amount of time to save. So I can't speak to whether or not another instance of Sigil would be unresponsive during that time. I can't even switch away from one instance quick enough to beat the save time. Are you saving to / opening from a network?

[jwes]

Originally Posted by DiapDealer

I've never had an epub take a "significant" amount of time to save. So I can't speak to whether or not another instance of Sigil would be unresponsive during that time. I can't even switch away from one instance quick enough to beat the save time. Are you saving to / opening from a network?

I have a very large epub with a few thousand images and it takes about 10 seconds to save.

[DiapDealer]

Originally Posted by jwes

I have a very large epub with a few thousand images and it takes about 10 seconds to save.

I don't have access to an epub large enough to even test whether or not a second instance of Sigil would be unresponsive during a save of a different instance.

[KevinH]

Originally Posted by jwes

I have two epubs open in two instances of Sigil. I save one, which takes a significant amount of time. The other instance of Sigil is unresponsive until the first one is finished saving. Is this expected behavior?

In your testing, is any other non-Sigil app responsive when Sigil is saving and compressing thousands of files? Especially to a remote or slow device?

On Linux and Windows two instances of Sigil should be totally independent processes that share a common set of ini files (and of course share system resources). On MacOS, these are two mainwindows with the same main process, so sharing the gui thread and sharing worker threads.

[jwes]

Originally Posted by KevinH

In your testing, is any other non-Sigil app responsive when Sigil is saving and compressing thousands of files? Especially to a remote or slow device?

On Linux and Windows two instances of Sigil should be totally independent processes that share a common set of ini files (and of course share system resources). On MacOS, these are two Windows with the same main process, so sharing the gui thread and sharing worker threads.

Other apps work fine and I am saving locally on Windows 11.

[KevinH]

How are you launching both instances? Are both launched by double-clicking, or the panel or ...? Do you have any executable properties set?

Perhaps it is a Qt thing? Do other Qt apps act the same way?

Please use your task manager and check if the two versions of Sigil overlapped in any way? Perhaps turning off the damn Windows Efficiency mode would help? Perhaps Windows itself is sleeping the other instance of Sigil?

I do not have a big enough test epub to try to recreate things on Linux. If you have access to Linux, you may want to test to see if it is an OS thing or not.

[DiapDealer]

I would try exempting the directory to where the huge file is being written from any antimalware scanning engines.

I could also see a ton of disk-thrashing going on. See if the same thing happens when saving the huge epub to disk when the second instance of Sigil is editing an epub from physically different drive. Could be a thumb drive if need be.

[KevinH]

Okay, I found a test epub that had 2500 junk xhtml files that I used for my rename testing. It takes a count to about 3 or 4 seconds to do a full save as on my lowly macOS laptop.

@DiapDealer, I emailed it to you directly in case you want it for testing.

With it under MacOS (which shares one process unlike Windows and Linux), the second instance of Sigil was unresponsive while the first version did its save as. But this is expected behaviour on Mac OS since they share all worker processes and even the main gui process.

I then fired up Linux in a multi-threaded VM and tried the exact same test. Linux uses completely separate processes for multiple instances of Sigil.
Linux allowed me to easily switch to the second instance of Sigil and start editing while the first did the save as in the background. Again, this is what I would expect for Linux and Windows.

I have no idea why your Windows box with fully separate main processes and separate worker threads does what it does. It is either something specific to Windows or to your set-up.

But this demonstrated that there is nothing inherent in Sigil's code that would force a clash or make things unresponsive on Windows and Linux -- just MacOS due to its inherent multi-mainwindow design on that platform.

So please use your task manager to turn off Efficiency Mode for all threads associated with both copies of Sigil before trying your test. Please let us know what you find.

[DiapDealer]

The junk.epub sample bought me enough time to do the test, so thanks for that! I was quite surprised that it took the better part of 20 sec for that epub to save on a fairly beefy Windows 11 machine! But regardless of that, the second instance of Sigil was still perfectly usable while the save on the first instance was ongoing. The results were the same on a Windows 10 machine. I made sure both epubs being edited were on the same physical disk (in the same directory).

The Windows 11 machine is not mine, so it's pretty bog-standard. No security stuff disabled.