Pull to refresh
8K+
11
Игорь Стовпец@stoi

Разработчик Go (а еще — Delphi, Android, C++)

4
Rating
5
Subscribers
Send message

С чего она потокобезопасная вдруг стала? Там просто всё в основном потоке, это ж VCL )). Потокобезопасность обеспечивает Винда. Цикл обработки сообщений крутится в главном потоке. Нет там нигде никакой синхронизации в коде Delphi. И я не про windowsMessage вообще, не про оконные сообщения и их обработку. Я про коллбеки обычные говорил. Типа - объект имеет поле “FOnCreate: TNotifyEvent” и другой объект в это поле кладет свой коллбэк: Obj.OnCreate := … И вот тут возникает связанность, от которой спасает паттерн Pub/Sub как раз.

Я сделал простейшие обертки для System.Messaging для работы в потоках. И если слать record-ы а не объекты - вообще проблем нет.

  TEvent = (eMenuUpdated, eResetSession, eReadDiscCard, eSettingsChanged,
    eStartScreenSaver, eStopScreenSaver);

  TCommonMessage = record
    Event: TEvent;
    Value: Variant;
    constructor Create(AEvent: TEvent; AValue: Variant);
  end;

  TCommonMessageListenerMethod = procedure(M: TCommonMessage) of object;

procedure SendCommonMessage(AEvent: TEvent; AValue: Variant); overload;
procedure SendCommonMessage(AEvent: TEvent); overload;
procedure QueueCommonMessageUIThread(AEvent: TEvent; AValue: Variant);
procedure SendMessage(AMessage: TMessage);
procedure RunUiThread(AThreadProc: TThreadProcedure);
procedure QueueUiThread(AThreadProc: TThreadProcedure);
procedure SendMessageUIThread(AMessage: TMessage);
procedure QueueMessageUIThread(AMessage: TMessage);
procedure SubscribeToCommonMessage(AListenerMethod
  : TCommonMessageListenerMethod);

implementation

procedure SendCommonMessage(AEvent: TEvent; AValue: Variant); overload;
begin
  SendMessage(TMessage<TCommonMessage>.Create(TCommonMessage.Create(AEvent,
    AValue)));
end;

procedure SendCommonMessage(AEvent: TEvent); overload;
begin
  SendCommonMessage(AEvent, 0);
end;

procedure QueueCommonMessageUIThread(AEvent: TEvent; AValue: Variant);
begin
  QueueUiThread(
    procedure
    begin
      SendMessage(TMessage<TCommonMessage>.Create(TCommonMessage.Create(AEvent,
        AValue)));
    end);
end;

procedure SendMessage(AMessage: TMessage);
begin
  TMessageManager.DefaultManager.SendMessage(nil, AMessage, True)
end;

procedure RunUiThread(AThreadProc: TThreadProcedure);
begin
  TThread.Synchronize(nil, AThreadProc);
end;

procedure QueueUiThread(AThreadProc: TThreadProcedure);
begin
  TThread.Queue(nil, AThreadProc);
end;

procedure SendMessageUIThread(AMessage: TMessage);
begin
  RunUiThread(
    procedure
    begin
      SendMessage(AMessage)
    end);
end;

procedure QueueMessageUIThread(AMessage: TMessage);
begin
  QueueUiThread(
    procedure
    begin
      SendMessage(AMessage)
    end);
end;

Ну вообще, я использовал раньше в проектах на Delphi подобный Notifiyer для сложных проектов, где один компонент должен уведомлять о чем-то в процессе работы другой компонент. Раньше для этого в Delphi использовали TNotifyEvent и подписывались, передавая хэндлер (коллбэк) - OnEvent. И всё это делало код очень связанным и запутанным. Так написан весь VCL в Delphi. Начиная с Delphi XE5 в нем появилась либа System.Messaging подобная тому, что я описал в статье. Использовать её после TNotifyEvent - просто кайф )). Собственно, глядя на неё и статью писал. И эти библиотеки не подразумевают хранение и передачу истории сообщений, динамическое подключение подписчиков. Это уже, на мой взгляд - другое. Это уже - брокер сообщений полноценный. Это гораздо больше. Как-то так )

Вы правы. Всё есть тут: https://github.com/istovpets/messaging/blob/master/messaging.go#L237 А в данной статье - нарочито упрощенный учебный пример.

Предполагается, что все подписки инициализируются при старте приложения. Как любые другие зависимости. Вы же не говорите, что, допустим, накладываются ограничения на HTTP сервер из-за того, что БД не инициализирована до его старта? Это не полноценный брокер сообщений для микросервисов и хранить сообщения он не должен, ИМХО. Впрочем, если нужен именно такой сценарий - нужно сочинять что-то другое, не спорю.

Ну если нештатно, тогда всё что угодно можно предполагать ). Тут и редиски с кроликами не помогут ))). Безусловно, в описанной тобой ситуации нужно не просто пулять сообщения, а что-то придумывать. Я когда писал либу и статью, ориентировался на System.Messaging в Delphi https://docwiki.embarcadero.com/CodeExamples/Athens/en/System.Messaging_(Delphi). По опыту знаю - очень удобная штука для сложных проектов. Кардинально уменьшает связанность и хаос в коде.

Это не проблема, ИМХО. Это же внутрисервисные сообщения - между компонентами одного приложения. Завершилась работа сервиса, завершились и внутренние сообщения и компоненты уничтожились. Это не замена Кролику )

Подписчик не может не вычитывать - это часть Notifiyer. Но вот если хэндлер подписчика будет долго тупить - заблокируется. В конце статьи есть об этом. В боевом коде конечно так лучше не делать. И в библиотеке я предусмотрел несколько стратегий на этот счет

"Не закрытый канал держит ресурсы. Закрывать надо явно." - поправьте пожалуйста. Нужно писать "Незакрытый" - слитно. Иначе меняется смысл предложения. Типа - "Не закрытый канал держит ресурсы (а открытый)".

Спасибо на добром слове )

Не готов спорить, о преимуществах коммунизма перед капитализмом и рынка перед планом )). Да и не то это место для подобных споров )).

Вы говорите совсем о другом ). Да, не один идиот себя идиотом не считает )).

Я больше 20 лет работал в компании, которая фактически была моей второй семьей. Был вовлечен, перерабатывал, всячески старался работать именно на результат, а не на себя. Компания платила мне взаимностью и в деньгах и в карьере и в льготах и в человеческом отношении. Жалею, что ушел оттуда...
Поверьте, такое бывает. Но видимо - редко.

С чего вдруг? Я про то что: Вы продаете своё время, свои способности, свою свободу. Если вы продаете честно качественный продукт и покупатель соблюдает условия договора - нет проблем.
И усложнять ни к чему, ИМХО.

Неверно. Если работодатель нормальный - вы работаете сообща и получается синергия. Если каждый из вас думает только о своей выгоде - получается шляпа, как ни старайся. Но справедливости ради - адекватный работодатель встречается нечасто. Мне вот повезло, когда я попал в 1С-Рарус. Но больше с таким не сталкивался...

Так кроме прочего, я сам ежедневно пользуюсь ИИ при разработке и не только. И знаю, где и как он может быть полезен, где - опасен в программировании )). Однозначно, никакой нормальный софт с помощью вайб-кодинга создать нельзя. Это будет шляпа )).

Про Кибердеда: Я таки ему больше склонен доверять, чем вам. "Советкскость" тут не при чем. Он аргументирует, а вы просто вешаете ярлык "советская газета".

Моё личное мнение: Языковая модель, использующая вероятностную статистику по определению не может писать полноценный код. И если самому ChatGPT правильно сформулировать вопрос - "Почему?", он сам вам о себе расскажет.
Вот пример:
https://www.linkedin.com/posts/istovpets_если-правильно-задать-вопрос-ии-он-сам-объяснит-activity-7432194691946840064-4_sW?utm_source=social_share_send&utm_medium=member_desktop_web&rcm=ACoAAEJkQY4BXOtXuHOzOy6UuD5_5wWo_AWx5bI

P.S. Просьба - ставить хоть какие-то знаки препинания. Последний ваш абзац нечитабелен ((.
"КосТность мышления" - пять баллов )). Извините, не удержался.

Выводы исходят и разрозненных источников. Новости, интервью, статьи. К сожалению, не сохранял ссылки. Ну например, вот: https://youtu.be/8Bm6LOFn6l8?si=RbotH9L3PgKELoIy

Абсолютно нормальное мироустройство. Ты честно работаешь, тебе честно платят. Когда вам за большую сумму продают бракованный негодный товар, вы тоже размышляете про общественное устройство?
Отношения между работодателем и работником - это обычный договор купли-продажи. Ты - мне, я - тебе ).

Да нет, почему же сразу болен? Это чувство стаи, чувство команды )). Если работодатель при этом адекватный - то только так и покоряются вершины ).

1
23 ...

Information

Rating
1,302-nd
Location
Сергиев Посад, Москва и Московская обл., Россия
Registered
Activity