История изменений

Я вот что понял: мы упираемся в две вещи. Если делаем жёстко синхронный режим, то должны висеть на сокете. Т.е. среда зависнет при долгом молчании сервера. Это недопустимо, т.к. чревато падением среды и потерей несохранённых файлов. Среда падать не должна. А раз мы не висим на сокете, то цикл обработки событий неизбежно работает и мы не сможем гарантировать синхронность между запросом на список листьев и возвратом из запроса. Т.е. сценарий b в том, что я написал (кстати, код здесь) не должен работать (хотя на вид работает).

Поэтому можно такой вариант сделать: У поддерева есть 4 состояния: неизвестно, ждём, заполняем, заполнили.

Первое состояние - «неизвестно». При запросе списка листьев вставляем лист со словом «ждите» и ставим состояние «ждём». Возвращаем управление - пусть tablelist раскроет список и покажет этот элемент. Не вставить элемент «ждите» нельзя, поскольку исчезнет треугольничек. В то же время асинхронно отправляем запрос на список листьев на сервер. По приходу списка листьев с сервера ставим состояние поддерева «заполняем», удаляем лист со словом «ждите» и заполняем настоящими данными. Ставим состояние «заполнено». Здесь мы всё делаем синхронно и проблем возникнуть не должно. Если список листьев пришёл, а состояние уже «заполняем» или «заполнено», то выбрасываем этот список. Слава Богу, у нас локалы должны каждый раз быть одинаковыми.

Это был сценарий b.

Сценарий a всё же представляет трудность. Но можно бросить мультибумеранг, а именно ставить на after idle (или во вторую очередь, или через таймер) скрипт следующего содержания:

if {поддерево $x заполнено} {
  искать в нём
} else {
  after idle тот-же-скрипт
}

Тогда поиск зависнет до момента заполнения дерева, и при этом вся система не будет висеть.

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

Верно я мыслю?

Я вот что понял: мы упираемся в две вещи. Если делаем жёстко синхронный режим, то должны висеть на сокете. Т.е. среда зависнет при долгом молчании сервера. Это недопустимо, т.к. чревато падением среды и потерей несохранённых файлов. Среда падать не должна. А раз мы не висим на сокете, то цикл обработки событий неизбежно работает и мы не сможем гарантировать синхронность между запросом на список листьев и возвратом из запроса. Т.е. сценарий b в том, что я написал (кстати, код здесь) не должен работать (хотя на вид работает).

Поэтому можно такой вариант сделать: У поддерева есть 4 состояния: неизвестно, ждём, заполняем, заполнили.

Первое состояние - «неизвестно». При запросе списка листьев вставляем лист со словом «ждите» и ставим состояние «ждём». Возвращаем управление - пусть tablelist раскроет список и покажет этот элемент. Не вставить элемент «ждите» нельзя, поскольку исчезнет треугольничек. В то же время асинхронно отправляем запрос на список листьев на сервер. По приходу списка листьев с сервера ставим состояние поддерева «заполняем», удаляем лист со словом «ждите» и заполняем настоящими данными. Ставим состояние «заполнено». Здесь мы всё делаем синхронно и проблем возникнуть не должно. Если список листьев пришёл, а состояние уже «заполняем», или «заполнено» то выбрасываем этот список. Слава Богу, у нас локалы должны каждый раз быть одинаковыми.

Это был сценарий b.

Сценарий a всё же представляет трудность. Но можно бросить мультибумеранг, а именно ставить на after idle (или во вторую очередь, или через таймер) скрипт следующего содержания:

if {поддерево $x заполнено} {
  искать в нём
} else {
  after idle тот-же-скрипт
}

Тогда поиск зависнет до момента заполнения дерева, и при этом вся система не будет висеть.

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

Верно я мыслю?