Неожиданный Z_STREAM_ERROR

[gildor2]

Неожиданный Z_STREAM_ERROR

[dimzon]

полез читать исходники- нашел!
короче z_stream_s надо пинить в памяти чтобы GC его не перемещал потому что zlib запонминает адрес z_stream_s при инициализации и потом перепроверяет его

[gildor2]

То есть проблема решена?

[dimzon]

Ну по хорошему я бы исправил (убрал одну проверку) из ZLib (deflate.c @ 361) но это уже тонкости...
Слуш а к bzip2 твой патч скоростной не прикрутить?

[gildor2]

Эта проверка - в самом zlib, а не в моём "патче". И по идее если эта проверка выдаёт ошибку - это что-то не так у ВАС, а не в zlib.
С bzip2 никогда дел не имел.

[dimzon]

И по идее если эта проверка выдаёт ошибку - это что-то не так у ВАС, а не в zlib.

не соглашусь, данная проверка основана на том предположении что адрес выделенной внешним кодом структуры не меняется с момента ее создания, при этом в описании api dll такого требования нету. у меня структура выделяется в т.н. managed -памяти, это означает что между вызовами zlib в результате работы сборщика мусора структура может поменять свой адрес (дефрагментация памяти). Каждый раз при вызове функции zlib я передаю ей правильный текущий адрес структуры, но Zlib запоминает адрес при первом вызове. Для обхода данной проверки мне пришлось помечать эту структуру особым образом (пинить в памяти) дабы сборщик мусора при дефрагментации памяти не трогал эту структуру. данный подход снижает эффективность работы сборщика мусора потому что в памяти образуются неперемещаемые куски...

[gildor2]

pin - это стандартная операция при смешивании C# и "нормального" языка программирования.

[dimzon]

pin - это стандартная операция при смешивании C# и "нормального" языка программирования.

одно дело запинить на момент вызова и распинить сразу после. другое дело держать запиненный объект пока файл не закрыт...

[gildor2]

Ок, тогда делаете аллокацию из C++/C кода, а не из C#. И в C# используете IntPtr. Опять же стандартная процедура. Мне к сожалению приходилось кодить на C# и я с разными стратегиями более-менее знаком.

[gildor2]

И кстати чем плохо "держать постоянно запиненый объект"?

[dimzon]

Ок, тогда делаете аллокацию из C++/C кода, а не из C#

тогда уж лучше Marshal.AllocHGlobal() из C#

И кстати чем плохо "держать постоянно запиненый объект"?

Из MSDN: "This prevents the garbage collector from moving the object and hence undermines the efficiency of the garbage collector." Т.е. образуется кусок нееремещаемой памяти что мешает GC работать "вообще" а не только для данного объекта...

У меня просто задача сгенерировать очень много PDF очень очень быстро... Я в iTextSharp-е столько неоптимальностей подфиксил сам в шоке, там используется managed-реализация zlib-а, я хочу поменять на unmanaged с точки повышения скорости. А GC там работает вовсю...

[gildor2]

zlib-объект будет только один, или много? Если один или несколько (не "много"), тогда особой разницы нет. Или же выделите память с системной куче (heap) - тоже не повлияет на GC, потому что .NET работает в своей куче.