[что почитать]Неблокирующиеся приложения....

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

З.Ы. А почему вопрос не в Development?

З.Ы. А почему вопрос не в Development?

Потмоу что ЖЖ, частично. Да и абстракная идея нужна.

>загрузка модели дерева, загрузка одной таблицы, из которой грузится другая и так пока не дойдем до нужной

это где такой ужас? Буду обходить стороной

>>загрузка модели дерева, загрузка одной таблицы, из которой грузится другая и так пока не дойдем до нужной

это где такой ужас? Буду обходить стороной

Извещения о завершении определенных операций. Не понимаю. Чего ты боишься?

ИМХО в приложениях подобного рода лучше всего использовать конечные автоматы. Тогда все получается красиво и удобно. Без них код легко может получится кривоватым. Хотя многое зависит от конкретного случая.

ИМХО в приложениях подобного рода лучше всего использовать конечные автоматы.

и как это будет выглядить при сохранении неблокируемости?

>и как это будет выглядить при сохранении неблокируемости?

Не совсем понял. Какого сохранения?

В сетевых приложениях если не используется блокирующее ожидание, то конечные автоматы достаточно распространенное явление.

Как какого, потребуются синхронизации, еще. Ибо вводится некий Автомат состояние коего должно быть непротиворечиво в рамках приложения, а до сего момента таких мест не было.

>Как какого, потребуются синхронизации, еще. Ибо вводится некий Автомат состояние коего должно быть непротиворечиво в рамках приложения, а до сего момента таких мест не было.

%) Видимо я чего-то не понимаю. Речь идет о неблокирующем вводе/выводе?

Обычно неблокирующий ввод/вывод используют в однопотоковых приложениях. Там нет никаких проблем с синхронизацией потоков по причине отсутствия таковых.

Может имелся ввиду избегание заморозки гуя за счет создания дополнительной рабочей нити, скажем при загрузке данных из сети?

Речь идет о неблокирующем вводе/выводе?

Нет. Абстрагируйся, есть некая долговременная задача, она закончилась, произошло событие, пронанализировав событие мы ждем завершения следующей задачи, которая, кстати может уже и выполнилась, так что каждый раз нужно тупо проверять и на время проверки захватывать блокировку чтобы синхронизировать состояние задачи

теплее, только там пул нитей 8)

>Нет. Абстрагируйся, есть некая долговременная задача, она закончилась, произошло событие, пронанализировав событие мы ждем завершения следующей задачи, которая, кстати может уже и выполнилась, так что каждый раз нужно тупо проверять и на время проверки захватывать блокировку чтобы синхронизировать состояние задачи

Эээ... Я правильно понял? Есть некоторая последовательность действий которую надо совершить и где-то в этой последовательности надо ожидать завершения других долговременных операций.

Если код, который выполняет эту последовательность в нити гуя, без конечного автомата обойтись будет трудно. Нити при завершении долговременных операций могут вызывать события конечного автомата с блокировкой на этом автомате. Гуй может вызывать события с блокировкой на этом автомате. Если реакция на событие конечного автомата достаточно короткая и автомат работает только с локальными данными, то такой подход пройдет.

Эээ... Я правильно понял?

Да, причем сформулировал это яснее. Настолько яснее что понятно куда копать.

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

Причем автомат потребуется чуть ли не для всего приложения, что не хорошо. В общем надо думать, но от литературки я не откажусь.

Хотя нет.

Я так понимаю ты на жабе пишешь. Там наверняка есть способ вызова процедур внутри гуевой нити из другой нити. Что-то типа дотнетовского Control.Invoke(). Вызывай все события в гуевой нити. Никакой блокировке вообще не делай. А последовательность действий пусть отрабатывает конечный автомат в гуевой нити.

s/Настолько яснее что понятно куда копать./Настолько яснее, что мне стало понятно куда копать./

Там наверняка есть способ вызова процедур внутри гуевой нити из другой нити. Что-то типа дотнетовского Control.Invoke(). Вызывай все события в гуевой нити.

Есть, EventQueue.invokeLater/inwokeAndWait, однако, глобальный автомат как и любая другая глобальная хрень мне не нравится. А если он будет не глобальным то будут теже яйца что и со слушателеями.

А наличие глобального окна в гуевой программе у тебя тоже вызывает тошнотворную реакцию?

оно не порождает лишних связей между моулями 8), т.е. не влияет на расширяемость, а с автоматом придется воротить феерический механизм добавления ветвей графа и кучу другого кода, не говоря о том что в такой реализации будет перекрыт стандартный механизм рассылки событий, по сути это будет костыль.

>феерический механизм добавления ветвей графа и кучу другого кода

Если без скриптовой системы, то это выглядит в виде абстрактного класса State с методами основных событий, нескольких его потомков и обычного массива который хранит все эти состояния.

Скриптовая система может все испога^W сильно усложнить.

Ну и функция SwitchTo(номер_состояния), которую если надо вызывают внутри методов-событий если хотят изменить состояние автомата.

>не говоря о том что в такой реализации будет перекрыт стандартный механизм рассылки событий, по сути это будет костыль.

Стандартный механизм событий не будет перекрыт никак.

Есть событие. Есть реакция на это событие. Все как было, так и осталось.

Если задуматься, то можно прийти к выводу, что любое гуевое приложение представляет собой неявный конечный автомат. Просто в твоем случае ты можешь это более четко формализовать.

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

Изучи паттерны проектирования Worker Thread и Future.

как всегда не по делу 8)

Да, да, вот за это нужно убивать, за глобальный список всех состояний 8)

>Да, да, вот за это нужно убивать, за глобальный список всех состояний 8)

Я не понимаю. В чем проблема? Сделай список локальным, если очень хочется.