Комментарии 9
Люблю Go.
Спасибо за библиотеку! Врятли её буду использовать, но чуть-чуть посмотрел её внутренности. Сразу несколько вопросов:
Почему используется глобальный стейт?
Если код порождает горутины - то почему нет возможности их из-вне прибить? Контекст там, или отдельный канал какой-нить для уведомления об этом.
Вот тут будет происходить блокировка до момента, пока предыдущие вызовы не будут обработаны, а если их будет много? Выглядит как узкое место
Структура вместо интерфейса для описания сообщения заставит код быть более связанным, что по идее не очень хорошо
Почему бы в дизайне не заложить то, что при подписке на события - просто передавать на вход канал, в который надо отправить сообщение, а при отписке наоборот - его принимать (пример можно глянуть тут)?
Спасибо за быстрое ревью!
Почему используется глобальный стейт?
Мы не можем понять как иначе поступить в данном случае? Может быть подскажете, направите?
Если код порождает горутины - то почему нет возможности их из-вне прибить? Контекст там, или отдельный канал какой-нить для уведомления об этом.
Вот тут будет происходить блокировка до момента, пока предыдущие вызовы не будут обработаны, а если их будет много? Выглядит как узкое место
Структура вместо интерфейса для описания сообщения заставит код быть более связанным, что по идее не очень хорошо
Спасибо! Поставили себе таски на доработки.
Почему бы в дизайне не заложить то, что при подписке на события - просто передавать на вход канал, в который надо отправить сообщение, а при отписке наоборот - его принимать (пример можно глянуть тут)?
А какое преимущество даст передача сообщений в каналы на ваш взгляд? Изначально мы решили не выбрасывать каналы наружу потому что не хотели чтобы они использовались напрямую в обход библиотеки.
Мы не можем понять как иначе поступить в данном случае
Да просто же:
func New() *State {
return &State{m: make(map[string][]chan Message{})}
}И уже на эту структуру состояния "навешивать" нужные функции (так и тестировать будет проще, и иметь возможность переиспользовать пакет в разных контекстах)
Поставили себе таски на доработки
Заметил :) Вам спасибо за то, что не игнорируете обратную связь!
А какое преимущество даст передача сообщений в каналы на ваш взгляд
Зона ответственности в первую очередь будет локализованной (тот, кто создаёт каналы и передаёт их вашей реализации "в работу"- занимается их обслуживаем и своевременным закрытием, вспомни signal.Notify(...); этот подход чем-то похож на Rust-овский), и это более "нативный" путь для Go, вспомни тот-же <-time.After(...)
Тоже писал что-то похожее для своего проекта, для разрешения блокировок добавил возможность указать время ожидания, по истечении которого запись в конкретный канал слушателя будет пропущена и выплюнута ошибка в канал ошибок (до этого иногда все приложение "вставало колом", если буфер канала на слушающей стороне переполнялся или если просто горутина там подвисала).
И каналы тоже передает подписчик, либо он может создаваться автоматически. В общем, интересное резюме для себя получил )) Спасибо за статью и за комментарий.
Для каких целей используется данная библиотека? При падении сервиса операция останется висеть в полуобработанном состоянии, т.к. события никуда не персистируются. Т.е. для критичной бизнес-логики не подходит. Для логирования - ОК. Возможно, стоит прописать это явно?
Имеет смысл ещё написать про реентрабельность. Напр., что будет, если я дёрну bell.Ring в обработчике?
Как дела с graceful degradation? Т.е. у нас крутятся тяжеловесные обработчики, а процесс нужно срочно стопануть. Как поведёт себя библиотека?
Хотелось бы подобных деталей.
Для каких целей используется данная библиотека? При падении сервиса операция останется висеть в полуобработанном состоянии, т.к. события никуда не персистируются. Т.е. для критичной бизнес-логики не подходит. Для логирования - ОК. Возможно, стоит прописать это явно?
Вы совершенно правы! Добавим в осписание сервиса что у нас нет персистентного хранения сообщений.
Имеет смысл ещё написать про реентрабельность. Напр., что будет, если я дёрну bell.Ring в обработчике?
В данный момент если из обработчика вызывать то же событие, то ничего не произойдет. Если вызвать другое событие, то будет вызван обработчик этого события.
Как дела с graceful degradation? Т.е. у нас крутятся тяжеловесные обработчики, а процесс нужно срочно стопануть. Как поведёт себя библиотека?
Сейчас graceful degradation у нас нет. Деградируем некрасиво (все просто прекратится на середине выполнения) :) Спасибо за наводку. Поставили таску на доработку.
Вот что бывает, когда разработчики приходят в Go и тащат свои привычные инструменты.
Библиотека весьма удобная и выглядит аккуратно, но в в Go есть каналы!
Колокол — система событий в Go или очередная event-system библиотека