Мохнатые уроды и моральные пёзды. Войти !bnw Сегодня Клубы
Привет, TbI — HRWKA! 1053.4 пользователей не могут ошибаться! Официальная конфочка бнвача: bnw@conference.jabber.ru
?5902
говно5817
прекрасное5171
говнорашка4445
хуита3850
anime2658
linux2442
music2274
bnw2231
log2020
рашка1941
pic1860
ололо1757
быдло1421
украина1326
гімно1109
дыбр1074
роботы_не_одобряют986
сталирасты849
bnw_ppl832

_ -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Полтора года назад (#UIOG94) я привлекал некоторое локальное сообщество к криптографии и никто из них сейчас ее не использует (или не пишет мне). Спасибо тебе, Роскомпозор, что ты заставляешь людей задуматься и пересмотреть свое отношение к инфопространству. Сегодня в течение дня пару человек спросили как обойти блокировки и обезопасить подключение к биткоин-бирже и зашифровать диск. Напомню, если у вас еще нет gpg-ключа - сейчас самое время его создать (лучше сразу GPG2.0 и эллиптические кривые), вангую, в скором будущем вам это тоже потребуется наряду с умением настроить прокси/впн/вдс с опенвпн. -----BEGIN PGP SIGNATURE----- iMsEARMKADEWIQS8yW2gSDhmrARXjkIsjs0AO3ulYgUCWtTanBMcamVydW5tYW5A Z21haWwuY29tAAoJECyOzQA7e6Vi/JACB2QytIJVVruLZNyQbuui/k4dOr/hzGxO 2o0cv+4dm3Gy/21fntAa/meHltb3QtDKFRDUhlwbysqiNnc2W4IILve0Aginl6lx OFFOXG51dEoQsLqhCz/zlLaBQTGEZbBgsTSELTRhEWjqzhN1K/zm9OA7v1C6ElBe YQhmhQ4DtlHhRRvGwg== =n4b3 -----END PGP SIGNATURE-----
#07FL8F (15+7) / @je / 7 дней назад
#РоссияВалить пора из России во все четыре стороны. С такими темпами, ничего хорошего в ближайшем будущем нас не ждёт. Фашисты проклятые! https://rublacklist.net/29198/
#2Q2TC8 (4) / @anonymous / 319 дней назад
Давайте обсосем одну задачку. Имеем линукс, имеем фс, имеем два и больше процессов и один файл. Необходимо синхронизировать процессы для доступа в запись/чтения одного файла. По-хорошему у нас должен появиться третий процесс, занимающийся этим в монопольном режиме с кэшированием. Но мы не будем делать по-хорошему, а попробуем положиться на средства ОС. Уточнение по задаче: процессы, взаимодействуя с внешним сервисом, получают информацию об актуальности некоторого статичного файла (грамматики, которую раздает nginx), в случае необходимости (если грамматика устарела) скачивают ее и сохраняют на диск. Как я уже сказал никакого менеджера очередей у нас не будет, процессы ничего не знают друг о друге, потому что, скажем, у нас дедлайны, а рулить доступ к ресурсам вообще может и должна ОС. Здесь мы замечаем flock(), имеется возможность создать назначать читателей вызовом flock(fd, LOCK_SH) и писателей flock(fd, LOCH_EX). Стандартное поведение нас практически устраивает, за исключением, что: если читаталей стало сильно много - писатели будут вставать в очередь, в большой конкуретности за это время будет накапливаться большая очередь из писателей, до того времени, пока не запишет хотя бы один, их очередь будет расти. Как только произойдет запись, уже не будет столь актуальным записывать еще тысячу раз одно и то же. Появляется искусственное ограничение - желание иметь в очереди записи всего 1 читателя, то есть блокировка должна выглядеть примерно так: flock(fd, LOCK_EX if LOCK_EX not in queue else LOCK_EX|LOCK_NB), что означает - если в очереди нет писателей, то встать в очередь записи с блокировкой, иначе попробовать захватить ресурс с LOCK_NB и получить отлуп по ошибке недоступности ресурса. Проблема в том, что механизм синхронизации на блокировании файлов даже сейчас это всего-лишь зайчатки нормального менеджера управления очередями, буквально никакого управления из клиентского кода очередью нет совсем, нет даже возможности ограничить очередь до 1. Вместо читателей и писателей теперь будем использовать lock_file, который будем забирать с LOCK_EX|LOCK_NB, как только кто-то хочет записать файл - захватывает этот ресурс и спокойно пишет в файл $FILENAME.new, как только дописал, то переносим новый файл mv $FILENAME.new $FILENAME, в этом случае (полагаясь на атомарность переименования) мы получаем безопасное чтение, каждый из читателей, не дожидаясь писателей, смогут прочитать целый файл, исключая неполного чтения. После записи отпускаем блокировку - задача решена. Использовать переименование вместо записи в исходный файл мы должны, чтобы обезопасить себя от того, что какая-то мразь (которую мы не контролируем, такая как nginx) все-таки прочитает неполный файл. Никогда не используйте примитивы синхронизации файловой системы, это сложная вещь, которая может выстрелить и которую вы будете дебажить очень много времени. Вместо этого расшаривайте память, пишите менеджеры очередей и не полагайтесь, что кто-то вместо вас обеспечит потокобезопасность одним простым вызовом. И вообще думайте о скалабельности чуть раньше, чем появится требования запустить второй и тысячный инстанс.
#4ADTXP (12) / @je / 486 дней назад
ipv6 ready BnW для ведрофона BnW на Реформале Викивач Котятки

Цоперайт © 2010-2016 @stiletto.