В переменных, которые наследуются замыканием, обрабатывающим связанные с данным сокетом события

Сейчас код на Perl

Я, собственно, пытался написать клиента для этого сервера на Julia - и застрял банально на том, что не понимаю, как хотя бы просто greetings header считать, который плюёт сервер после установления соединения

Замыкания на перле ! Это 5

Должно переносится легко

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

А в Julia нет возможности сделать неблокирующее чтение без ccall'ов - и это довольно странно. При этом внутри read в Julia не может быть блокирующим, это тупо цикл из неблокироующих чтений

Если немного понимаете Perl, можете посмотреть Mojo::IOLoop::Delay, например - это просто каскад асинхронных вызовов. Наглядная архитектура, основанная на epoll'е как раз.

В принципе у меня каждый ответ на команду имеет ID, так что можно в отдельном "как бы потоке" читать блокирующим образом и если у считанного есть префикс ID - смотреть, зарегистрирован ли для данного префикса обработчик и вызывать его. А если нет обработчика или нет ID, как в случае с greetings header, - ничего не делать. Тогда можно из основного потока выдать N запросов серверу подряд, поставив на каждый из них обработчик, а читающий "поток" каждый такой обработчик запустит, если и когда придёт ответ от сервера. Правда, если не придёт, то ... да, можно запустить ещё одну нить, которая будет просматривать очередь ещё не обработанных сервером запросов и если в этой очереди есть слишком долго не отвеченные - вызывать обработчик.

Вы бы лучше рассказали что вы делаете. А не как. Вы пытаетесь мне описать молоток и воспроизвести его в джулии. Здесь эти задачи решаются по другому.

По-моему я описал абсолютно универсальный механизм реализации асинхронного взаимодействия в рамках поточной модели. У меня, кстати, такой молоток нигде не реализован, поскольку пока хватало обычного на libev основанного цикла опроса событий.

Ну и вроде для Julia-то это как раз основной механизм

Задача в 2-х словах такая:

1) Нужно отдавать серверу команды и не ждать ответа на них, но уметь обрабатывать этот ответ, когда он всё-таки будет получен
2) Нужно слежить за тем, чтобы не было команд, которые ушли на сервер, но не получили ответа в течение некоторого "разумного" количества времени

И да, Борис, я Вас, возможно, удивлю, но сейчас всё программирование на perl - это сплошные замыкания, код на perl в этом плане больше напоминает код на javascript. И это понятно, поскольку и там, и там - цикл опроса событий и асинхронные обработчики в рамках однопоточной модели.

Надеюсь никто не обидится на использование чата в качестве стековерфлоу. Поделитесь, пожалуйста, своими соображениями вот по какому вопросу. Написал я вот свой тип с большим количеством полей. А теперь появилась необходимость разных проверок по этим полям: насколько они соответствуют некому набору правил. Вопрос в том, как бы вы это реализовали.

с помощью if conditions and assert macros в outer and/or inner constructors?

Вот вопрос у меня в этом и стоит. Вынести это во внешние конструкторы и сделать там. Или лучше все это как-то провернуть во внутренних конструкторах

Понятно, что сделать можно и так, и так. Интересно есть ли какая-то разница с точки зрения разработчиков

я думаю без разницы - во внешних или внутренних

Понятно. Спасибо. Поищу может еще что-нибудь на эту тему на просторах интернетов.