Previous Entry Share Next Entry
2016-01

(no subject)

Вот кто-то наконец нормально расписал, почему многопоточный UI -- это тяжело. Можно. Перформанс местами выигрывается. Но тяжело и поэтому не масштабируется в смысле разработки.

https://weblogs.java.net/blog/kgh/archive/2004/10/multithreaded_t.html

This entry was originally posted at http://wizzard.dreamwidth.org/451454.html. It has comment count unavailable comments. Please comment there using OpenID.

  • 1
(Deleted comment)
justy_tylor November 2nd, 2015
Масштабируется как нефиг делать. На очередях замыканий, разумеется, не на жабьих локах.

Через "выполни замыканице у себя" основной UI удобно синхронизировать и с воркерами, и с другими UI (например, где асинхронно документ рендерится).
Прочая инфраструктура (понятия задач, стейкхолдеров, etc) наворачивается уже поверх.

blackyblack November 2nd, 2015
Примерно та же дрянь, что event driven UI.

jakobz November 2nd, 2015
Это же жесть жестяная. Они правда что-ли это в каких-то библиотеках делали? Ну, т.е. в коде была не просто event-driven лапша - когда в неизвестном порядке, неизвестно что, меняет общий стейт, а это еще и делалось параллельно, да еще и разруливалось локами?

_winnie November 2nd, 2015
Да так всё в жизни и происходит. Взять хотя бы то, как пользователи поезда входят и выходят в поезд.

thedeemon November 2nd, 2015
В BeOS (и Haiku) весьма приятно было сделано: у каждого окошка свой тред и своя очередь сообщений. Все многопоточненько, отзывчиво, но без явных локов и проблем с дедлоками, все общение через message passing. Одно удовольствие.

kodt_rsdn November 2nd, 2015
Под беос не работал, не могу сказать, насколько это всё приятно. Но.

Тут вопрос о гранулярности.

В виндах (да и в других расхожих осях) типичная ситуация - один UI-поток на всё приложение. Ну в крайнем случае - один поток на top-level окно - это как бы несколько приложений, запущенных в одном процессе.

Если завести потоки у каждого виджета, у каждого контрола, - то получим ту самую ситуацию, описанную в статье: восходящие и нисходящие движения, которые нужно разруливать или введением асинхронности (очередями сообщений), или танцами с бубном.

Один поток на дочернее окно достаточно крупной и изолированной сущности, пусть содержащее в себе кучу более мелких виджетов?
Тогда либо у тулкита должны быть два (три) класса объектов: [приложение], окно, виджет; либо программист сам говорит: этому окну свой поток, а это пусть живёт в потоке родителя.

thedeemon November 3rd, 2015
Там последний вариант (и первый подвариант) : контролы это не окна, есть приложение, есть окна (содержащие контролы и имеющие свои очереди и свои потоки) и есть контролы, которые умеют реагировать на сообщения от окна.
https://www.haiku-os.org/legacy-docs/bebook/TheInterfaceKit_Overview_Introduction.html

sab123 November 2nd, 2015
Проблемы так или иначе есть с долгоиграющей обработкой. Она вылазит и с тредами и с событиями.

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

zeit_raffer November 3rd, 2015
Интересно, пробовал ли кто делать GUI в Java через Akka?
Ну, чтобы без этих багопротивных локов.

maxim November 3rd, 2015
У нас в эрланге как и в BeOS может быть хоть по своему потоку на кнопку.
Любая кнопка может заспавнить свой именованый поток.
Проблемы такое писать когда ты пользуешь не теми примитивами.
Я раньше думал что BeOS это заебись, пока N2O не написал.
А джава чуваки конечно пусть жрут свою лапшу.

Я кстати даже на WPF на .NET запускал по 8 потоков для кнопок чтобы по ядрах все разбрасывалось (на каждого ядро по reader+writer).


Edited at 2015-11-03 12:56 pm (UTC)

  • 1
?

Log in

No account? Create an account