Сообщение Re[13]: SynchronizationContext a-la node.js от 03.10.2016 21:04
Изменено 03.10.2016 21:06 Serginio1
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>> По сути это и есть дэдлок.
S>> Аналогично будет и при использовании SynchronizationContext
S>Бинго!
S>Про это и писал выше по ветке,
S>
S>Т.е. как только появляется необходимость запихнуть в одну очередь произвольный код — начинаются грабли.
Ну дык куча приложений работает с SynchronizationContext и никаких граблей не отхватывает. Та же 1С по такому принципу работает и дедлоков не отхватывает.
Просто для каждой задачи свой подход.
S>> Другое дело, что задачу топикастера, можно решать параллельные задачи с шедулером
S>Ну да. Или сами себе создаём проблемы с узким местом — очередью сообщений, или городим синхронизацию (и снова рискуем огрести из-за логической ошибки) или отказываемся от изменяемого разделяемого состояния вообще. Последнее как-то проще в итоге выходит.
Ну на самом деле у меня была задача при работе с Вацапом. Куча народу отправляли сообщения через один номер.
Отправлять нужно с задержками. В очереди может скапливаться по нескольку сообщений, но их недостаточно, что бы забить очередь до отказа.
S>Здравствуйте, Serginio1, Вы писали:
S>> По сути это и есть дэдлок.
S>> Аналогично будет и при использовании SynchronizationContext
S>Бинго!
S>Про это и писал выше по ветке,
S>
S>Для тасков так делать нельзя, дедлок | забитую очередь отхватить можно
S>...
S>Но топикстартеру надо "SynchronizationContext который бы сериализовал колбэки"...
S>Вызывать калбэки напрямую или ч/з await тут роли не играет, проблема с самими задачами.
S>Т.е. как только появляется необходимость запихнуть в одну очередь произвольный код — начинаются грабли.
Ну дык куча приложений работает с SynchronizationContext и никаких граблей не отхватывает. Та же 1С по такому принципу работает и дедлоков не отхватывает.
Просто для каждой задачи свой подход.
S>> Другое дело, что задачу топикастера, можно решать параллельные задачи с шедулером
S>Ну да. Или сами себе создаём проблемы с узким местом — очередью сообщений, или городим синхронизацию (и снова рискуем огрести из-за логической ошибки) или отказываемся от изменяемого разделяемого состояния вообще. Последнее как-то проще в итоге выходит.
Ну на самом деле у меня была задача при работе с Вацапом. Куча народу отправляли сообщения через один номер.
Отправлять нужно с задержками. В очереди может скапливаться по нескольку сообщений, но их недостаточно, что бы забить очередь до отказа.
Re[13]: SynchronizationContext a-la node.js
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>> По сути это и есть дэдлок.
S>> Аналогично будет и при использовании SynchronizationContext
S>Бинго!
S>Про это и писал выше по ветке,
S>
S>Т.е. как только появляется необходимость запихнуть в одну очередь произвольный код — начинаются грабли.
Ну дык куча приложений работает с SynchronizationContext и никаких граблей не отхватывает. Та же 1С по такому принципу работает и дедлоков не отхватывает.
Просто для каждой задачи свой подход. Вплоть до разруливания дедлок аналогично как в SQL (Кодт помню выкладывал алгоритм).
S>> Другое дело, что задачу топикастера, можно решать параллельные задачи с шедулером
S>Ну да. Или сами себе создаём проблемы с узким местом — очередью сообщений, или городим синхронизацию (и снова рискуем огрести из-за логической ошибки) или отказываемся от изменяемого разделяемого состояния вообще. Последнее как-то проще в итоге выходит.
Ну на самом деле у меня была задача при работе с Вацапом. Куча народу отправляли сообщения через один номер.
Отправлять нужно с задержками. В очереди может скапливаться по нескольку сообщений, но их недостаточно, что бы забить очередь до отказа.
S>Здравствуйте, Serginio1, Вы писали:
S>> По сути это и есть дэдлок.
S>> Аналогично будет и при использовании SynchronizationContext
S>Бинго!
S>Про это и писал выше по ветке,
S>
S>Для тасков так делать нельзя, дедлок | забитую очередь отхватить можно
S>...
S>Но топикстартеру надо "SynchronizationContext который бы сериализовал колбэки"...
S>Вызывать калбэки напрямую или ч/з await тут роли не играет, проблема с самими задачами.
S>Т.е. как только появляется необходимость запихнуть в одну очередь произвольный код — начинаются грабли.
Ну дык куча приложений работает с SynchronizationContext и никаких граблей не отхватывает. Та же 1С по такому принципу работает и дедлоков не отхватывает.
Просто для каждой задачи свой подход. Вплоть до разруливания дедлок аналогично как в SQL (Кодт помню выкладывал алгоритм).
S>> Другое дело, что задачу топикастера, можно решать параллельные задачи с шедулером
S>Ну да. Или сами себе создаём проблемы с узким местом — очередью сообщений, или городим синхронизацию (и снова рискуем огрести из-за логической ошибки) или отказываемся от изменяемого разделяемого состояния вообще. Последнее как-то проще в итоге выходит.
Ну на самом деле у меня была задача при работе с Вацапом. Куча народу отправляли сообщения через один номер.
Отправлять нужно с задержками. В очереди может скапливаться по нескольку сообщений, но их недостаточно, что бы забить очередь до отказа.