tcl threads

tokuchu

Maurog

tokuchu

опиши подробнее о чем речь,

какая версия Tcl

какой код

что за потоки, биндинги

или только о скрипте речь и тд

Maurog

• расширить это расширение и вывести эту команду в скрипт, благо, расширение на sf выложено с кодом
   
• можно, написать клиенский Си-код, который доступится до внутренних хендлов этой либы и прибьте поток
   
• можно все же грамотно сделать, а именно поддержать кенселинг на уровне скриптов и прежде, чем выходить, дождаться выхода всех потоков
   

Maurog

зы: я правильно понимаю, что речь о таком расширении? http://wiki.tcl.tk/2770

#if 0

/* only Windows 2000 (XP, too?) has this function */

HANDLE (WINAPI *winOpenThreadProcDWORD, BOOL, DWORD);



void

ThreadpInit (void)

{

    HMODULE hKernel = GetModuleHandle("kernel32.dll");

    winOpenThreadProc = (HANDLE (WINAPI *DWORD, BOOL, DWORD

	    GetProcAddress(hKernel, "OpenThread");

}



int

ThreadpKill (Tcl_Interp *interp, long id)

{

    HANDLE hThread;

    int result = TCL_OK;



    if (winOpenThreadProc) {

	hThread = winOpenThreadProc(THREAD_TERMINATE, FALSE, id);

	/* 

	 * not to be misunderstood as "devilishly clever",

	 * but evil in it's pure form.

	 */

	TerminateThread(hThread, 666);

    } else {

	Tcl_AppendStringsToObj(Tcl_GetObjResult(interp

		"Can't (yet) kill threads on this OS, sorry.", NULL);

	result = TCL_ERROR;

    }

    return result;

}

#endif

tokuchu

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

во-первых, можно тебе прочитать лекции про вредность этой операции, про утечки ресурсов

Dasar

т.к. там всё же отдельный интерпретатор порождается как я понял,

tokuchu

тогда лучше отдельный процесс пускать, если уж хочется так кого-нибудь убить

Dasar

С процессом возни больше. И не уверен, что с ним будет так же просто связаться.

tokuchu

а с тредом ты как связываешься?

если ты при этом утверждаешь, что интерпретаторы там разные

Maurog

Т.е. там нет никакого thread::terminate и "выводить" его туда тоже не кому.

tokuchu

не можешь собрать свою версию threads с терминейтом?

tokuchu

Maurog

Ну и потом если бы это было так просто, то они бы и сами это сделали бы. Разве нет?

Dasar

все должно работать предсказуемо, в случае ошибок красивые ошибки должны летать. понимаешь?

tokuchu

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

Maurog

И его поэтому не сделали, т.к. оно unsafe?

tokuchu

tokuchu

да, так считаю. потоки терминейтить - это плохо

kokoc88

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

tokuchu

Потребность есть, и она решается выходом из функции потока.

kokoc88

Я про случай когда тред занят обработкой чего-нибудь. Допустим какого-нибудь тяжёлого запроса к БД. А нам надоело ждать и мы решили его завершить.

tokuchu

В таком случае красивым решением было бы начинать операцию в БД с таймаутом в самом потоке.

Dasar

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

kokoc88

Я не про таймаут говорил, а про "внезапную" отмену. Т.е. когда таймаута как такового нет, но может поступить команда извне, что "хватит".

tokuchu

kokoc88

Ну первый способ на "красивый" нифига не тянет.

А остальные требуют специальных возможностей от интерфейса БД или ещё чего.

tokuchu

Второй и третий способы вообще ничего не требуют. Если только у тебя не абсолютно примитивная платформа без возможности передавать данные между потоками без событийной модели; или без аналога pthread condition.

kokoc88

Ну конечно? А асинхронный вызов к БД, который можно "одновременно" ждать?

ava3443

асинхронный вызов к БД

The optional -async argument specifies that all com-
mands allowing asynchronous (nonblocking) operation
will do so. The commands affected are: oraparse,
oraexec, orafetch and those that make use of these such
as orasql, orabindexec and oraplexec. These commands
will immediately return a code of OCI_STILL_EXECUTING
which is equal to the numeric value of -3123. Repeat
calls to these commands with the same arguements until
a return value of OCI_SUCCESS, a 0, is retuned. See
the section below on ASYNChrONOUS TRANSACTION HANDLING.

tokuchu

Конечно.

может быть только примитивная многопоточность в TCL

tokuchu

Не знаю, какая у тебя БД, и вообще с tcl дела пока не имел, но например в случае Oracle, судя по man oratcl, асинхронно работать можно - по ссылке и пример есть.

kokoc88

Ну так это разве не специальные возможности?

И да, например, тот интерфейс к БД, который есть у меня (ODBC какой-то) — он синхронный.
Да и не обязаны все интерфейсы быть асинхронными.

А знание того, что БД подключена через сокет и его закрывание — это уже из области хаков. В том смысле, что я тоже не назвал бы это красивым, т.к. это специфичное решение.

tokuchu

Нет, это не специальные возможности.

Для реализации почти всех моих подходов асинхронные интерфейсы не являются необходимыми.

Для реализации почти всех моих подходов асинхронные интерфейсы не являются необходимыми.

Я написал, что этот способ кривой.

kokoc88

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

И для этого тоже? Я про него писал:

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

tokuchu

одновременно ждать завершения команды в БД и сигнала отмены

kokoc88

Не то скопипестил. Как это можно делать синхронно:

tokuchu

В винде waitformultipleobjectsex, в phtreads парой compareandexchange и condition; можно ещё вспомнить про семафоры, select/poll, и так далее...

kokoc88

И это по твоему синхронно?

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

ava3443

я не могу поллить работающий запрос

tokuchu

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

Закрываешь запрос к БД и всё.

В рабочей программе потоки не убивают.

tokuchu

в ODBC тоже есть non-blocking режим (SQLSetConnectAttr либо SQLSetStmtAttr с аттрибутом SQL_ATTR_ASYNC_ENABLE).
Сидишь в цикле пока код возврата == SQL_STILL_EXECUTING, каждый проход цикла проверяешь, нужно ли работать дальше, или пора прерваться. Что сложного?

kokoc88

Как? Если у меня поллинга нету на него?

Я собственно спрашивал мнения: "или я не должен этого хотеть". А ты начал говорить, что есть красивые решения, я уже обнадёжился.

Хотя вон Сергей говорил, что такая проблема у него тоже есть, ну по крайней мере в теории.

kokoc88

И это только пример, рассматривай это как данность в данном вопросе, что есть блокирующийся интерфейс к чему-либо.

Dasar

В .NET можно реализовать все 4 метода, и частично пятый.

kokoc88

нет никаких 5 методов

Dasar

На практике есть, и больше пяти.

kokoc88

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

согласен, что таких хаков и частных случаев - вагон и маленькая тележка

Dasar

Чтобы поддержать дискуссию, привёл бы свои решения, которые ты использовал на практике.

tokuchu

Из другого потока. Я же написал: в методе с закрытием сокета вовсе необязательно должен быть сокет. Обычно при этом в поток, который делает запрос, возвращается какая-нибудь ошибка.

Они есть, и я их привёл, чтобы обосновать мнение, что "ты не должен хотеть убивать потоки". В чём проблема-то, я должен был просто написать "не должен" и всё? Я предпочитаю хоть как-то аргументировать свои посты.

kokoc88

Ну как же я верну ему ошибку? Я не могу ему ничего "подсунуть". Для этого нужны те самые "специальные возможности".

У меня "красивые" не вяжутся с "не должен". Т.е. ты вроде говоришь, что они красивые, но так же говоришь, что они плохие, но есть. У меня на это диссонанс. Если они делают плохо, то они некрасивые. Красивые — это когда хорошо, да ещё и элегантно.

Сергей дело говорит, что всё что ты предлагаешь — это передалать синхронный код в асинхронный. А меня интересовало как раз как можно было бы синхронный код завершить.

Тем более, что в TCL он обрабатывается в отдельном интерпретаторе и в принципе есть потенциальная техническая возможность всё это дело аккуратно подчистить.

For example, TerminateThread can result in the following problems:
•If the target thread owns a critical section, the critical section will not be released.
•If the target thread is allocating memory from the heap, the heap lock will not be released.
•If the target thread is executing certain kernel32 calls when it is terminated, the kernel32 state for the thread's process could be inconsistent.
•If the target thread is manipulating the global state of a shared DLL, the state of the DLL could be destroyed, affecting other users of the DLL.

tokuchu

Зачем тебе возвращать ошибку? Закрываешь запрос к БД из одного потока; библиотека для работы с БД знает, что нужно закрыть внутри (сокет, пайп или что-то другое); в поток, который ждёт выполнения операции, приходит ошибка (вообще средствами ОС).

то красивыми считаются те решения, которые правильно работают

Ты не понимаешь ни его, ни меня, ни мнения других людей, которые тут высказались. ... Я тебе ещё раз повторяю, что как минимум 2, 3 и 4 способы - это синхронные решения; поэтому сначала разберись в теме, и не веди себя как упёртый туповатый лошок.

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

Нет никакой возможности "подчистить" потоки операционной системы.

Прежде чем лезть спорить с кем-то в этом разделе и выставлять себя полным бараном, тебе следует хоть немного изучить документацию на любой API для терминации потоков:

kokoc88

Блин. Но библиотека должна же будет что-то вернтуть на запрос.

Да мне кажется это ты тут чего-то не понимаешь и пытаешься доказать непонятно что. И я тебе ещё раз повторяю, что можешь называть их как хочешь — синхроннымили и т.п. Но смысл в том, что у тебя это не простой вызов интерфейсной функции, которая возвращает результат. Тебе это трудно осознать что ли?

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

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

Dasar

kokoc88

кстати, вот это http://tmml.sourceforge.net/doc/tcl/Cancel.html - это не то, что ты хочешь?

Dasar

tokuchu

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

result = do_some_long_calculation_or_whatever_shit(params)

Тот факт, что ты не можешь понять того, что я пишу, вовсе не означает, что это хуйня.

Прервать заблокированный в ядре поток

tokuchu

кстати, вот это http://tmml.sourceforge.net/doc/tcl/Cancel.html - это не то, что ты хочешь?

kokoc88

При таком вызове мы ждём результата работы. Как при этом можно ещё ждать команду отмены?

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

Dasar

tokuchu

Use exceptions, Luke!

Судя по твоим ответам, тебе пока что не понятно.

tokuchu

многое зависит от того, что именно они называют asynchronous handlers

kokoc88

Эта функция не возвращает исключения, !
Ты умышленно меня троллишь?

Да нет, это судя по тому, что ты пишешь, тебе не понятно что спрашивают и ты пишешь про что-то своё.

kokoc88

многое зависит от того, что именно они называют asynchronous handlers

tokuchu

Нет, я пытаюсь выяснить, как твоя функция возвращает ошибку. Точно так же, один в один, она вернёт ошибку при прерывании ожидания из другого потока.

Конечно, мне не до конца понятно, что именно ты спрашиваешь. Только проблема не во мне.

kokoc88

1) Как это относится к случаю "ждём одновременно отмену и возврат ответа"?

2) Ну да, ошибки как-то возвращаются. Это тут при чём? С этим вопросов нет. Но как другой поток прервёт ожидание? Для этого нужна спецфункция, разве нет? Или есть какой-то магический способ сделать это без неё?

Ну да, логично вместо уточнения вопроса написать что попало в ответ и начать спорить?

kokoc88

Как это относится к случаю "ждём одновременно отмену и возврат ответа"?

kokoc88

1) Как это относится к случаю "ждём одновременно отмену и возврат ответа"?

tokuchu

Ты либо беспросветно туп, либо находишься на расстоянии светового года от темы разработки многопоточного кода. Попытаюсь объяснить тебе на пальцах, как ребёнку в детском саду, может быть поймёшь. Представь себе такую модель (именно модель, потому что вряд ли такой код заработает): выполняем синхронный recv а затем закрываем сокет из другого потока.
Ты вообще не читаешь, что тебе пишут? Другой поток может закрыть соединение с базой данных, которая знает что нужно закрыть на уровне операционной системы (сокет, пайп, или что-нибудь ещё). Закрытие объекта операционной системы возобновит работу потока, который выполняет синхронное ожидание в ядре. Таким образом, для сокета ты получишь примерно ту же картину, что получил бы при отсутствии соединения с базой данных.

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

Чтобы не приходилось тебе рассказывать и доказывать, что 1+1=2 или 10.

kokoc88

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

Ну это, наверное, самое тупое твоё утверждение в этом треде.

Т.к. я тебе пытаюсь объяснить свою ситуацию, а ты мне почему-то тупо продолжаешь рассказывать про свою, доказывать что-то.

ava3443

Это ты либо туп, либо не читаешь и тупо троллишь.

tokuchu

Давай подведём короткий итог дискуссии. Ты спросил, есть ли в других языках/платформах потребность останавливать потоки и как она решается. Я ответил, что есть и привёл примеры решения. После чего ты, так и не заботав матчасть, начал рассказывать про необходимость каких-то специальных возможностей. Я тебе почти сразу ответил: если в твоей библиотеке/платформе не поддерживается ни одного из приведённых мной методов или их аналогов, то ты не сможешь остановить поток по требованию.

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

tokuchu

тебе уж и так, и так распинается, объясняя разные способы как это обычно делают,

а тебе лень даже элементарно дать ссылку на используемую тобой библиотеку и пример твоего кода.

kokoc88

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

kokoc88

Я говорил, что суть не в конкретной библиотеке. Интересно было обсудить общие принципы.

tokuchu

что "сбился с мысли" и почему-то начал это на описанное мною применять

tokuchu

А я тебе о каких принципах написал? Я же привёл несколько практических решений, которые применяются в mainstream языках: C#, Java, C++

kokoc88

то под поставленные мною критерии оно не попадает

tokuchu

Какие критерии? Пока что единственный критерий, который я вижу, примерно такой: есть write-only код while(true) { } и его надо прервать по требованию.

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

Dasar

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

tokuchu

Я так понимаю, что ты этот ответ даёшь касательно C#, Java, C++?

kokoc88

так в этом вопрос и состоял: есть ли такие принципы..

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

kokoc88

Именно так! Да, да. Меня именно и только это интересует.

Dasar

Щито?

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

kokoc88

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

Dasar

В каком смысле я не проговариваю это явно?

kokoc88

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

tokuchu

И при этом ты понимаешь разницу между while(true) и recv?

tokuchu

slonishka

Шесть! Девять!