в тикле тоже &

Имеется ввиду выполнение в фоне тиклевской команды.

Re^2: Аналог & в Tcl

> Имеется ввиду выполнение в фоне тиклевской команды.

"фоновый" режим там отсутствует как вид. Классическая tcl-ная программа однопоточна.

Однако, имеется libtclthread, по названию которой можно догадаться, что она позволяет делать.

Да, решение подходит, спасибо.

>"фоновый" режим там отсутствует как вид

подавился бубликом. а after, vwait и fileevent там тогда для чего ?

>Классическая tcl-ная программа однопоточна

философия Tcl не предполагает прямого доступа к абстракции потока, но из этого отнюдь не следует её однопоточность. причём использовать потоки ОС вместо своих "лёгких" внутренних потоков Tcl Core тоже может - для этого достаточно собрать интерпретатор с соответствующим ключом

вообще фееричное утверждение, особенно неожиданное от человека, который на Tcl (насколько я помню) регулярно пишет

> а after, vwait и fileevent там тогда для чего ?

это тоже "фееричное утверждение, особенно неожиданное от человека,
который на Tcl (насколько я помню) регулярно пишет"

мусье не отличает событийную систему от многопоточной?

>мусье не отличает событийную систему от многопоточной?

приехали. ты хоть глянул на какой вопрос я отвечал ? а для реализации работы в фоновом режиме - нет, не различаю. и Остерхаут не различает. даже пишет об этом, не скрывая подробностей : http://www.softpanorama.org/People/Ousterhout/Threads/index.shtml

ещё будут столь же прекрасные вопросы ?

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

>подавился бубликом. а after, vwait и fileevent там тогда для чего ?

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

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

фоновое выполнение запускается с помощью after, в самом простом случае с помощью after idle - т.е. выполнить код как только появится возможность. а внутри блока кода уже можно ожидать изменения : after idle { vwait ::var }

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

вполне. единственный подводный камень именно в Tcl/Tk - команда exec игнорирует стандартный event loop; чтобы этот момент обойти написали bgexec :

http://www-bio3d-igbmc.u-strasbg.fr/doclib/blt/bgexec.html

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

>т.е. я правильно понял, что после выполнения каждого оператора, тикль проверяет список отложенных событий и реагирует на одно из них? как если бы пользователь вручную ставил после каждого оператора after idle.

совершенно не понял вопроса. вот man по after, предлагаю ознакомиться прежде чем спрашивать что-либо ещё : http://www.tcl.tk/man/tcl8.5/TclCmd/after.htm

Re^4: Аналог & в Tcl

>>"фоновый" режим там отсутствует как вид

> подавился бубликом. а after, vwait и fileevent там тогда для чего ?

ну так можно и программу с alarm() считать имеющей "фоновый" режим :)

>>Классическая tcl-ная программа однопоточна

> философия Tcl не предполагает прямого доступа к абстракции потока, но из этого отнюдь не следует её однопоточность. причём использовать потоки ОС вместо своих "лёгких" внутренних потоков Tcl Core тоже может - для этого достаточно собрать интерпретатор с соответствующим ключом

Кстати я это так и не осилил :) Линк дашь?

>фоновое выполнение запускается с помощью after, в самом простом случае с помощью after idle - т.е. выполнить код как только появится возможность. а внутри блока кода уже можно ожидать изменения : after idle { vwait ::var }

Здорово. Казалось бы, причём тут выполнение в моменты простоя, но то, что нужно.

> вполне. единственный подводный камень именно в Tcl/Tk - команда exec игнорирует стандартный event loop;

зато open не игнорирует :)

set fd [ open /path/to/apps "r" & ]
fileevent $fd readable [ list handle_app_out_proc $fd ]

>зато open не игнорирует :)

ну, собственно bgexec и является обёрткой вокруг open

>ну так можно и программу с alarm() считать имеющей "фоновый" режим :)

паттерн Proactor из ACE не использует многопоточность, основываясь на системных механизмах асинхронного ввода-вывода - так что же, не относить его к механизмам параллелизации из-за этого ? как по мне, главное - выполняется ли поставленная задача, а как именно - вопрос качества дизайна - и подход Tcl в этом плане один из самых красивых. к слову сказать в QNX Neutrino примитивы синхронизации POSIX дополнены набором функций, практически один в один дублирующих механизм after/vwait. в общем, jedem das seine

>Кстати я это так и не осилил :) Линк дашь?

http://www.tcl.tk/doc/howto/thread_model.html

"...by default, Tcl 8.4 is compiled without thread support and without script-level access to threads...so, now you can just build Tcl 8.3 (or 8.4) with threads enabled and load the thread extension..." - к 8.5 это также относится

А как проверить, что Tcl скомпилен с script-level access to threads при включённом thread? (В Debian по-умолчанию set tcl_platform(threaded)даёт 1.)