Tcl/Tk и threads

А зачем тут морочиться с тредами? Переводишь порт в неблокирующий режим fconfigure $com_port -blocking 0 и ставишь обработчик входящих данных fileevent $com_port readable <script> . И ничего замерзать не будет. Или как вариант можно тупо запустить обработчик в цикле с помощью after в стороне от основной программы и периодически считывать из буфера порта что туда накапало. И так и так делал. Чтобы не замораживать, главное порт в -blocking 0 перевести.

А зачем тут морочиться с тредами? Переводишь порт в неблокирующий режим fconfigure $com_port -blocking 0 и ставишь обработчик входящих данных fileevent $com_port readable <script> .

У меня как раз -blocking 0 и выставлен, но с файлэвентами не разобрался. Беда в том, что работа с портом «не однообразная» — некоторые операции предполагают просто ожидание, при этом данные могут прийти в произвольный момент времени; а некоторые операции — подача команды и получение ответа на нее. Мне показалось, что в этом случае использование тредов уместно.

Многоптоковые Tcl-сценарии

это уже классика

Многоптоковые Tcl-сценарии

это уже классика

Дык читал. Но о взаимодействии с Tk там написан только один абзац, да и тот о том, что невозможно shared variables использовать в качестве -textvalue. А мне примерно это и надо :-)

И там же смотрите раздел Save-Tcl

комбинаций и вариантов есть много.
все зависит от задач и нагрузки.

Ну еще (для ориентира)
В лоб (без потоков) мне удавалось принимать на скорости 57 килобод поток по tty и обновлять графики на экране.

В лоб (без потоков) мне удавалось принимать на скорости 57 килобод поток по tty и обновлять графики на экране.

Но КАК?(с)

У меня в однопоточной версии на скорости 9600 во время приема данных (около килобайта) интерфейс «замораживается». Делать update после каждого полла ком-порта имхо нехорошо.

Вообще — на wiki.tcl.tk взаимодействие с внешними устройствами описано очень скупо. Я использую один из описанных там методов — периодический опрос. Работает нормально, за исключением вот этих «замораживаний» во время приема. Ну и иногда на команду внешнее устройство может не ответить — на время этого таймаута тоже «подмораживается» интерфейс.

И там же смотрите раздел Save-Tcl

Не понял, это-то тут причем? Понятно, что создание треда запускает новый интерпретатор. Предлагаешь создавать алиасы для нужных переменных? Выглядит как-то не очень... Хотя посмотрю внимательнее, спасибо за наводку.

комбинаций и вариантов есть много. все зависит от задач и нагрузки.

Это ясно. Просто примеров понятных не нашел.

>Но КАК?(с)
Это надо смотреть исходники.
Чуть потом. Ok ?
ps: Давненько это уже было. По памяти не охота в дебри вас заводить.

Чуть потом. Ok ?

ps: Давненько это уже было. По памяти не охота в дебри вас заводить.

Договорились, заранее спасибо.

Если этот тред канет в бездну веков — мои контакты есть в профиле. Буду благодарен за любую информацию.

После чисток, вырезаний и борьбы с склерозом получилось что-то такое )) :
http://tcl.pastebin.com/gtbfKPpJ

Насколько я понял, у ТС происходит замораживание не из-за собственно чтения порта, раз он стоит в blocking 0, а во время обработки полученных данных, видимо, слишком тяжелая. Тогда да, лучше вынести в тред. Или оптимизировать обработку данных.

После чисток, вырезаний и борьбы с склерозом получилось что-то такое ))

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

Насколько я понял, у ТС происходит замораживание не из-за собственно чтения порта, раз он стоит в blocking 0, а во время обработки полученных данных, видимо, слишком тяжелая.

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