воскресенье, 7 ноября 2010 г.

CL-ZMQ v0.2

Потихоньку пилю сабж. Основными отличиями от ветки 0.1 - сломанное API :) Как-то:
  • Классы-врапперы заменил на структуры. Классы были нужны, как собаке пятая нога.
  • FFI'шные контекст и сокет тоже обёрнуты во врапперы. Соответственно, RAII макросы with-foo выкинуты, ибо теперь можно let'ом обойтись. Надо ещё подумать, как оставить возможность закрытия контекста и сокета до того, как объект будет прибран сборщиком мусора.
  • Функции msg-data-as-{foo} заменены на msg-{foo}. Диспетчеризацию по кейворду не стал делать, нафиг надо.
  • Для неблокирующегося режима нужно знать код EAGAIN. Раньше только ради этого требовался целый iolib.syscalls, который через cffi вычислял реальный код. Сейчас решил iolib выбросить и захардкодить значение(я). Через cffi-grovel тоже не хочу вычислять.
  • poll (пока сломан) будет дополнен конструктором полл-сетов, чтобы не консить каждый раз в with-poll, создающий полл-сет динамически.
  • Будет возможность переиспользовать уже выделенную память сообщений с помощью штатного setf.
  • Может быть, переименую константы в lispy-вид, т.е. добавятся плюсики по бокам. Или сделаю их кейвордами, но это будет несколько тормознее в рантайме, т.к. нужно будет искать значение кейворда.
Так, в принципе, не сильно всё меняется, поэтому особо жёстко софт фиксить не придётся. Но всё равно 0.2 хочу привязать к выходу следующей версии 0MQ, у которой будет сломано API.

В репозитории на repo.or.cz изменения лежат в бранче v0.2.

8 комментариев:

  1. Мне отчаянно не нравится with-poll, да и вообще полл :(

    Давай придумаем какой-нибудь дсл сюда. Что-инбудь типа:

    (zmq:with-multiplexing
    (incoming-msg msg-a from socket-a (process-msg msg-a))
    (queue-outgoing msg-a to socket-b)
    (multiplex))

    Макрос with-multiplexing пусть объявляет полл-объект и соответствующие локальные макросы "incoming-msg" / "queue-outgoing", которые раскрываются в нужные pollitem'ы с соответсвующими действиями, а multiplex будет звать zmq:poll.

    Если интересно, я могу накидать реализацию поверх существующего API, с парой примерой использования (из моей практики).

    ОтветитьУдалить
  2. Ну если только отдельной библиотекой... Смысла воротить реактор внутри малюсенькой библиотеки для обмена сообщениями нет.

    Кстати, реактор обещают в самом libzmq.

    ОтветитьУдалить
  3. Да, но в текущем виде это голый биндинг, тобишь, по-сути, чуток удобней, нежели напрямую библиотеку через alien-funcall звать.

    В любом случае, пользователь начинает с того, что наращивает CL-жир вокруг :) Я просто предлагаю стандартизировать его уже в библиотеке. RAII для контекста и сокетов -- хорошо, но этого все равно мало.

    ОтветитьУдалить
  4. Стандартизировать? Во всего одном из 20 (или сколько их там уже) биндингов?

    И с тобой не согласится чувак, который в своём форке cl-zmq оторвал даже raii ;)

    ОтветитьУдалить
  5. Ну блин, значит надо назвать это не биндингом, а как-нибудь messaging library based on 0mq :)

    Смысл в том, чтобы взять библиотеку, и сразу начать использовать ее в своем CL-проекте, минуя этап "олиспизации" стандартного си-API.

    Как минимум, сишный интерфейс ужасно неудобен для экспериментов в REPL, и даже with-* тут нихрена не спасает. Хотя бы кучу необходимых хелперов надо включить в стандартную поставку, раз dsl не хочешь :)

    ОтветитьУдалить
  6. Ты вот сам-то писал что-нибудь реальное, с использованием cl-zmq? :) Я вот да (правда, это был демонстрационный веб-стенд для одного внутреннего проекта, но он все равно был обширным :))

    ОтветитьУдалить
  7. > Соответственно, RAII макросы with-foo выкинуты, ибо теперь можно let'ом обойтись.

    Финализаторы, это, конечно, хорошо, но а) теоретически они есть не везде (практически - почти везде), б) если вдруг на используемой реализации их нет - tg:finalize тупо ничего не сделает и даже не ругнётся, а ты получишь утечку ресурсов (теоретически факт того, что финализатор установлен, можно проверить по возвращаемому tg:finalize значению), в) даже если финализаторы работают, как-то некрасиво это откладывать уничтожение объекта (который в принципе может быть связан с "дорогими" ресурсами в виде системных сокетов) до не очень хорошо известного момента (ибо при определённых настройках сборщика мусора он может запускаться довольно редко).

    Я бы with-xxx всё-таки оставил - это просто, понятно, надёжно и в большинстве случаев этого достаточно. А когда недостаточно - можно и удалять объекты руками или полагаться на финализаторы.

    > Сейчас решил iolib выбросить и захардкодить значение(я). Через cffi-grovel тоже не хочу вычислять.

    Очень неправильное решение. Захардкоженное значение 11 верно только для линуха, на freebsd, к примеру, EAGAIN=35, а 11 - это EDEADLK; а систем ещё есть много разных... А какие претензии у тебя к cffi-grovel? Он ведь именно для этого вроде и создавался.

    ОтветитьУдалить
  8. > Финализаторы, это, конечно, хорошо, но а) теоретически они есть не везде

    Практически, cl-zmq не работает везде без допиливания - у разных реализаций разное видение стандарта, поэтому на одной код может гладко работать, а на другой ругаться :) Поэтому "везде" пока ограничен четырьмя реализациями: SBCL, CLISP, Clozure и LispWorks.

    > в) даже если финализаторы работают, как-то некрасиво это откладывать уничтожение объекта

    Именно этими же мыслями я и руководствовался изначально. Но, как показала практика, люди НЕ используют биндинг в нагруженных проектах, где временная утечка памяти/дескрипторов на что-то влияла.

    Собственно, я всё ещё думаю, как с этим бороться, см. в программном выступлении пункт два ;) И ещё ведь можно использовать непосредственно CFFI'шные обёртыши.

    > Я бы with-xxx всё-таки оставил - это просто, понятно, надёжно и в большинстве случаев этого достаточно.

    Ok.

    > Очень неправильное решение. Захардкоженное значение 11 верно только для линуха, на freebsd, к примеру, EAGAIN=35, а 11 - это EDEADLK; а систем ещё есть много разных...

    Это я знаю. Но также знаю, что кроме линукса, фрибсд и винды биндинги нигде не запускались. Поэтому у меня возник соблазн захардкодить только реально используемые варианты. К тому же, функциональнось, где eagain требуется - она такая... Не очень популярная, скажем.

    > А какие претензии у тебя к cffi-grovel? Он ведь именно для этого вроде и создавался.

    Раньше для этого iolib использовался, но он становится всё большим и большим монстром. Подавляющуюся часть времени загрузки cl-zmq грузится iolib. Ради одного только eagain таскать его как-то не хочется.

    К cffi-grovel претензний нет, есть только желание ради eagain не вводить монстров. Вот когда мильон ioctl'ных констант от V4L2 надо было обработать, там grovel в тему. Тут же всего одна константа...

    ОтветитьУдалить

Архив блога