d
сейчас с одним потоком я обхожу это таймером, работает, кстати, не очень
Size: a a a
2020 July 12
АК
он может войти в блокирующий модальный цикл сообщений и не выходить от туда, при этом будет спать большую часть времени
А в чем проблема в UI потоке просто посылать задачи в тредпул и затем просто асинхронно ждать, выполняя сообщения окна?
d
А в чем проблема в UI потоке просто посылать задачи в тредпул и затем просто асинхронно ждать, выполняя сообщения окна?
с этим нету проблем, но просто даже если в пуле юзер явно закажет один поток, который будет являтся и UI-тредом, по факту их будет 2
d
пул под капотом создаст скрытый поток
I
но он не всегда выполняет ui...?
АК
с этим нету проблем, но просто даже если в пуле юзер явно закажет один поток, который будет являтся и UI-тредом, по факту их будет 2
ну да, их и должно быть два - один поток окна, другой меин. На маке том же по де факту создается два потока, один из которых - поток окна
d
ну да, их и должно быть два - один поток окна, другой меин. На маке том же по де факту создается два потока, один из которых - поток окна
а на маке разве ui не фиксировано в мейне?
АК
а на маке разве ui не фиксировано в мейне?
нет
АК
По этой причине Zombie окна работают в macOS
d
ну на винде тоже не фиксированно, но при выходе из мейна рантайм прибивает все потоки и их окна тоже
АК
Я про то, что если main thread зависает, но поток окна не должен вместе с ним зависать
d
ну да, их и должно быть два - один поток окна, другой меин. На маке том же по де факту создается два потока, один из которых - поток окна
примерно так и хочу, только наоборот, мейн будет ui потоком, а второй таски крутить
АК
примерно так и хочу, только наоборот, мейн будет ui потоком, а второй таски крутить
дык меин тред же только обслуживать подсистемы должен, а не работать с окном
АК
иначе проблем со синхронизациями будут
I
Я вижу это так. Есть меин поток, он обновляет все системы, и ui тоже - обновляет как, а так:
С помощью тред пула все что можно делать а синхронно с подпиской на события или ecs style, вот то и обновляет в других тредах, являясь инициатором забивания тредов задачами.
С помощью тред пула все что можно делать а синхронно с подпиской на события или ecs style, вот то и обновляет в других тредах, являясь инициатором забивания тредов задачами.
d
дык меин тред же только обслуживать подсистемы должен, а не работать с окном
ничего он не должен, всё что от него надо, это создать окно инициализировать рендер состряпать объект пула, наставить в него задач и приатачится к пулу, на том всё
АК
ничего он не должен, всё что от него надо, это создать окно инициализировать рендер состряпать объект пула, наставить в него задач и приатачится к пулу, на том всё
ну это то ясно, но зачем в меин треде держать окно? Почему не использовать отдельно просто флюш окна, а отдельно апдейт всего?
d
ну это то ясно, но зачем в меин треде держать окно? Почему не использовать отдельно просто флюш окна, а отдельно апдейт всего?
окно должно быть создано в ui-потоке на винде
d
ну это то ясно, но зачем в меин треде держать окно? Почему не использовать отдельно просто флюш окна, а отдельно апдейт всего?
точнее в том потоке где виндовую очередь сообщений собираешься крутить
АК
У нас например в ECS системе так и сделано: для окна создается отдельный поток, в котором просто заполняется буфер, а из главного потока берется и запускается пул задач, который затем синхронизируется с виндоу потоком