writing to METS must be atomic

[bertsky]

I frequently get an empty METS file when interrupting (ctrl+c) a long run of ocrd process. This I cannot even restore with ocrd workspace backup. IMO the interrupt must be suspended as long as the file is open for writing.

[kba]

I.e. attaching a handler to SIGTERM on entering workspace.save_mets() and removing it on leaving?

[bertsky]

I.e. attaching a handler to SIGTERM on entering workspace.save_mets() and removing it on leaving?

I guess so. But you mentioned save_mets as a possible point of conflict for parallelization efforts earlier, so perhaps this should already become a mutex/sema.

[kba]

mutex/sema

Since parallelization isn't going to be implemented in threads, wouldn't we need some filesystem-based mechanism for that, i.e. a lock file for the mets.xml?

Anyway, parallelization issues are more complex, this particular issue can be solved relatively easy, so let's do that first.

[bertsky]

Since parallelization isn't going to be implemented in threads, wouldn't we need some filesystem-based mechanism for that, i.e. a lock file for the mets.xml?

True!

Anyway, parallelization issues are more complex, this particular issue can be solved relatively easy, so let's do that first.

Agreed!