В одном из соседних топиков вычитал, что клиенту запрещено создавать несколько потоков одновременно, рабата со следующим потоком должна происходить только после закрытия уже предыдущего. А возможно ли устранить это ограничение?
У меня давно в голове витает идея сделать связку между 7z.dll и каким-нибудь драйвером файловой системы, например Docany, что бы иметь возможность монтировать архивы как полноценные диски. Даже запилил рабочий прототип, позволяющий монтировать 7z как диск. С форматами типа zip или 7z все однозначно – их нужно распаковывать либо в память либо на диск и отдавать данные оттуда. Но в ситуации с форматами типа tar дополнительная распаковка – это очень сильный overhead. Было бы гораздо эффективнее при запросе драйвера данных получать поток через GetStream и вычитывать данные напрямую через него. Но поскольку драйвер файловой системы может иметь несколько открытых файлов, то ограничение только на один поток делает связку 7z.dll + драйвер не очень эффективной. Да, можно каждый раз при чтении блока данных открыть поток, прочитать, и тут же закрыть, но это бьет по перфоменсу.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
7-zip data is backed entirely by stream-based interfaces that are not atomic and therefore can't be shared across threads.
There are several ways to help solve the atomic reading problem, here's two:
Rewrite IInStream so that Read and Seek are a single operation
Add a new interface such as ICloneable to clone an IInStream so that each instance could have its own guaranteed seek position.
Either way, every single handler would have to be revisited to support this, and it would require hundreds of hours of work and testing, and would require all 3rd party developers to rewrite their custom plugins to be thread safe and atomic.
There are other issues such as callbacks that would also have to be analyzed for thread safety.
Making 7-zip objects thread safe would be almost a rewrite of the library.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
В одном из соседних топиков вычитал, что клиенту запрещено создавать несколько потоков одновременно, рабата со следующим потоком должна происходить только после закрытия уже предыдущего. А возможно ли устранить это ограничение?
У меня давно в голове витает идея сделать связку между 7z.dll и каким-нибудь драйвером файловой системы, например Docany, что бы иметь возможность монтировать архивы как полноценные диски. Даже запилил рабочий прототип, позволяющий монтировать 7z как диск. С форматами типа zip или 7z все однозначно – их нужно распаковывать либо в память либо на диск и отдавать данные оттуда. Но в ситуации с форматами типа tar дополнительная распаковка – это очень сильный overhead. Было бы гораздо эффективнее при запросе драйвера данных получать поток через GetStream и вычитывать данные напрямую через него. Но поскольку драйвер файловой системы может иметь несколько открытых файлов, то ограничение только на один поток делает связку 7z.dll + драйвер не очень эффективной. Да, можно каждый раз при чтении блока данных открыть поток, прочитать, и тут же закрыть, но это бьет по перфоменсу.
7-zip data is backed entirely by stream-based interfaces that are not atomic and therefore can't be shared across threads.
There are several ways to help solve the atomic reading problem, here's two:
Either way, every single handler would have to be revisited to support this, and it would require hundreds of hours of work and testing, and would require all 3rd party developers to rewrite their custom plugins to be thread safe and atomic.
There are other issues such as callbacks that would also have to be analyzed for thread safety.
Making 7-zip objects thread safe would be almost a rewrite of the library.
This is not a problem for me. I make all calls to the 7z library functions through the critical section.