Два с половиной года назад я представил два скрипта: Google Cache Dumper и Bing Cache Dumper. Как нетрудно догадать по названию, их задача состояла в вытаскивании страниц заданного сайта из кэша соответствующего поисковика.

Оба скрипта я поставил на продажу по цене в $2 и $1 соответственно, и до сих пор их поддерживал. В качестве площадки для продаж по принципу наименьшего сопротивления я выбрал сервис Digiseller. Могу сказать, что на протяжении долгого времени меня всё более чем устраивало: скрипты потихоньку продавались, мне капала копеечка на хостинг, людям — польза в виде возможности хотя бы отчасти восстановить потерянный сайт.

Однако, в минувшем году Digiseller преподнёс один за другим два неприятных сюрприза. Сначала он потребовал персональный аттестат WebMoney для продажи через магазин на своем домене. Большой нужды у меня в этом сертификате не было, руки до него вечно не доходили, так что я пошел по пути наименьшего сопротивления: перенес продажи на их площадку-партнера plati.ru. Но и там был через некоторое время заблокирован без объяснения причин, о чем вчера узнал из комментов. Никаких уведомлений на почту, ничего.

Поразмыслив, я понял, что самым честным решением будет попросту открыть исходники этих скриптов, чему и посвящен этот пост.

Отныне и навсегда, оба эти скрипта размещаются на GitHub под славной лицензией WTFPL. Вы можете скачивать и использовать скрипты на свое усмотрение, а так же улучшать их и присылать пулл-реквесты:

1. Google Cache Dumper (скачать последнюю версию).
2. Bing Cache Dumper (скачать последнюю версию).

P.S. Если вы подумали, что в качестве картинки к посту я разместил задницу, то это вовсе не так. Это не задница, а стилизованная буква W, официальный логотип лицензии WTFPL. Сравните с ©.

Я хочу рассказать об одном нестандартном применении механизма сессий в PHP. Вспомнилось мне это в связи с позавчерашним постом Тормоза на тему, что опять в Даосе проблема с параллельным доступом к файлам - функция блокировки дала очередной сбой. И хотя Тормоз в комментах уже писал, что обкатывает исправленный алгоритм, успешно выдерживающий стресс-тест, я все же поделюсь своим решением. Сразу оговорюсь, все нижеизложенное было проделано just for fun и имеет свои недостатки. Зато и работает практически безотказно.

Перейду к технической части. По умолчанию механизм сессий в PHP использует хранилище данных в файлах - каждая сессия лежит в своем файле. При этом, чтобы обеспечить целостность данных используется нехитрый подход эксклюзивной блокировки доступа к файлу. Иными словами, в момент, когда мы делаем session_start(), движок PHP захватывает файл с требуемой сессией и отпускает ее только в момент явного вызова session_write_close() или завершения скрипта. И если в то время, пока мы работаем с сессией в рамках одного запроса, произойдет еще один запрос, использующий ту же сессию, то он заблокируется на session_start() до тех пор, пока первый не освободит файл. Обычно разные клиенты работают в разных сессиях и проблемы не возникает, однако (немного огрубляю) у одного и того же клиента в один момент времени исполняется только один запрос.

Реально проблема встает, когда во время выполнения некоторого длительного запроса (стримминг потока или long polling) надо обеспечить клиенту возможность посылать и другие запросы (ходить по страничкам) и вовремя получать ответы. Решают задаю обычно одним из трех путей:

1. Реализуют полностью свой механизм сессий.
2. Переопределяют обработчики операций с данными сессии во встроенном механизме (с помощью session_set_save_handler(), этим вариантом я в свое время и воспользовался).
3. Как можно раньше освобождают сессию с помощью session_write_close().

Но я отвлекся. В нашем случае мы не только не будем избавляться от этого, но наоборот будем использовать для реализации мьютекса: будем создавать сессию с заранее известным session_id, к примеру db_mutex, выполнять критические действия и закрывать сессию. Именно эту функциональность и реализует мой класс PHP_Mutex.

Надо признать, такой подход имеет ряд недостатков по сравнению с полноценными мьютексами:

1. Захватить можно не более одного мьютекса в одно и то же время.
2. Механизм хранения сессий не должен быть переопределен.
3. Если вы при этом используете стандартный механизм сессий, возможны потери данных сессии, поскольку на время использования мьютекса блокировка на файл основной сессии снимается.

Но если все условия удовлетворены (кстати, класс по мере возможности сам отслеживает потенциально проблемные ситуации и выдает ворнинги), то блокировка будет железной - разработчики PHP постарались, чтобы данные сессии были в безопасности в любой среде окружения :) Поэтому класс вполне сгодится в небольших скриптах типа Даоса, где сессии не очень нужны. Ну а в сложных системах можно прибегнуть и к тяжелой артиллерии вроде встроенных семафоров, у которых лишь один недостаток - по умолчанию они отключены.

Сам класс вы найдете во вложении, распространяется он свободно согласно лицензии New BSD License. Если кому пригодится - на здоровье :-)

Для одного из моих проектов, над которым я сейчас активно работаю понадобилось сделать возможность выполнения длинных запросов с "обратной связью", т. е. с возможностью отсылки информации о ходе выполнения скрипта. Поскольку подключать к проекту какого-нибудь монстра типа JQuery ради одной этой возможности я посчитал нецелесообразным, решено было написать свою простую библиотеку, выполняющую эту функцию. результат я представляю вам в этом посте.