[erlang] Сапожник без сапог

[netch80]

С тем, что нельзя открыть файл-устройство, уже столкнулись (отвечает eisdir'ом, хотя совсем не каталог). В рассылках нашлось обоснование - мол, "а что если оно заблокируется на ожидании?" (я вообще-то /dev/urandom пытался открыть, и это мои проблемы, если что-то заблокируется). А сегодня новое. Цитирую коллегу...


Я обнаружил интересную фичу: если файл открыт с опцией compressed, то
file:position/2 за пределы файла напрочь завешивает всю е-ноду вплоть до
момента, пока кто-то не допишет в этот файл нужное количество данных. При
этом нет разницы, зазипован ли файл на самом деле. А ведь единственный
способ узнать реальный размер зазипованных данных - это поблочно прочесть
его весь до eof`а!!!


Интересно, сколько ещё таких недопараллельностей таится в "параллельной" среде...

Comments

[gegmopo4.livejournal.com]

Вообще-то говоря иногда размер содержится в заголовке. Если это не поточный gzip, конечно.

[netch]

Вот именно, что поточный.

[trivee.livejournal.com]

Поглядеть так снаружи - ну и проблемы у вас там...

А я вот сегодня обнаружил, что в стандарте написано одно:

All input and output signals have 16-bit word lengths, which are limited to a range of -16384 to 16383 in 2’s complement notation.

а в reference implementation сделано совсем другое (-32768..32767, естественно). И уже 15 лет это никого не волнует...

[netch80.livejournal.com]

Очаровательно. У IETF такое есть, но это же не IETF, а наверняка ISO? Для них такие ляпы нетипичны...

[zyxman.livejournal.com]

Это примерно такого-же уровня проблема, как установить фрю на нестандартное железо - ну не обкатано оно на этом классе задач, потому нужно вспомнить что такое демократия и жить дальше ;)