Вопрос по TThread и RTL
Пытаюсь создать поток....типа пишу
Thread = new TMyThread(false);
вылетает при диманической RTL и не вылетает без нее.....ПОЧЕМУ!
Народ вот проблема.....
Пытаюсь создать поток....типа пишу
Thread = new TMyThread(false);
вылетает при диманической RTL и не вылетает без нее.....ПОЧЕМУ!
Потоки это батенька Вам не халам балам, вот держи кусочек, странслируй (ему пофиг RTL не RTL) если поймешь почему он то работает, то не работает - поймешь все.
Теперь вдогонку. Тема ПОТОКИ (возможные неприятности). Типа, я накололся, Вам возможно поможет.
1) Потоки и процессы - не одно и то-же (элементарно, но многие этого не понимают)
2) Потоки есть - Ваши, а есть не ваши, но они ЕСТЬ, и сделали их Вы, НО при этом Вы не видите (по крайней мере сразу) что это Вы их породили.
3) cmd.exe или bat файл в режиме MS-DOS - такой-же поток и если Вы думаете, что он одинаков под разными операционками - то Вы ОШИБАЕТЕСЬ. =>
4) Ждать ожидания конца потока (процесса) (смотри RSDN) конечно можно и более того НУЖНО. НО кто сказал, что например - запись дискового файла пройдет раньше, чем закончится поток (который Вы отслеживаете) А КЭШ на что.
5)Отсюда вывод - пишите эмуляторы процессов - у меня сейчас это правило, никакая документация не даст окончательного ответа на Вашу ситуацию.
Потоки это батенька Вам не халам балам, вот держи кусочек, странслируй (ему пофиг RTL не RTL) если поймешь почему он то работает, то не работает - поймешь все.
Теперь вдогонку. Тема ПОТОКИ (возможные неприятности). Типа, я накололся, Вам возможно поможет.
1) Потоки и процессы - не одно и то-же (элементарно, но многие этого не понимают)
2) Потоки есть - Ваши, а есть не ваши, но они ЕСТЬ, и сделали их Вы, НО при этом Вы не видите (по крайней мере сразу) что это Вы их породили.
3) cmd.exe или bat файл в режиме MS-DOS - такой-же поток и если Вы думаете, что он одинаков под разными операционками - то Вы ОШИБАЕТЕСЬ. =>
4) Ждать ожидания конца потока (процесса) (смотри RSDN) конечно можно и более того НУЖНО. НО кто сказал, что например - запись дискового файла пройдет раньше, чем закончится поток (который Вы отслеживаете) А КЭШ на что.
5)Отсюда вывод - пишите эмуляторы процессов - у меня сейчас это правило, никакая документация не даст окончательного ответа на Вашу ситуацию.
Теперь вдогонку. Тема ПОТОКИ (возможные неприятности). Типа, я накололся, Вам возможно поможет.
1) Потоки и процессы - не одно и то-же (элементарно, но многие этого не понимают)
2) Потоки есть - Ваши, а есть не ваши, но они ЕСТЬ, и сделали их Вы, НО при этом Вы не видите (по крайней мере сразу) что это Вы их породили.
3) cmd.exe или bat файл в режиме MS-DOS - такой-же поток и если Вы думаете, что он одинаков под разными операционками - то Вы ОШИБАЕТЕСЬ. =>
4) Ждать ожидания конца потока (процесса) (смотри RSDN) конечно можно и более того НУЖНО. НО кто сказал, что например - запись дискового файла пройдет раньше, чем закончится поток (который Вы отслеживаете) А КЭШ на что.
5)Отсюда вывод - пишите эмуляторы процессов - у меня сейчас это правило, никакая документация не даст окончательного ответа на Вашу ситуацию.
:D :D :D :D :D
Ну и бред...
Последователь Виталия Гриненко?
Хорошо ребята с RSDN твоих постулатов не видят.
Все, здец, устал, трижды пытаюсь подсоеденить кусок в тристо кил, и трижды получаю месаж - БИГ. Что за хрень. Винда, сайт, эксплорер, приморили.
:D :D :D :D :D
Ну и бред...
Последователь Виталия Гриненко?
Хорошо ребята с RSDN твоих постулатов не видят.
При чем тут ребята с RSDN? (тем более что я к тем ребятам тоже отношусь, вроде как). Хочешь по теме, давай конкретно, а пургу гнать не к чему. Если БРЕД - давай конкретно. ГДЕ бред?
:D :D :D :D :D
Ну и бред...
Последователь Виталия Гриненко?
Хорошо ребята с RSDN твоих постулатов не видят.
Ну, хрен с горы, ты куда делся, я уже с работы ухожу, что замолчал, защитник RSDN. Давай отвечай. Если я из виндовой прграммы стартую через cmd батник, в котором проворачиваю дисковые операциии при взведенном КЭШ и низком приоритете, то что получится? Чего ожидать? А то серанул и скрылся, красавец.
При чем тут ребята с RSDN? (тем более что я к тем ребятам тоже отношусь, вроде как). Хочешь по теме, давай конкретно, а пургу гнать не к чему. Если БРЕД - давай конкретно. ГДЕ бред?
Ну пургу (про потоки) это ты прогнал...
Трудно указать в большом бреду его отдельные бредовые части. Я лучше укажу, что в твоем изречении не бред:
1) Потоки и процессы - не одно и то-же
Не бред, но ты бы объяснил, в чем разница, раз хочешь просветить народ.
Все остальное не поддается здравому осмыслению.
Но можно постараться понять.
2) Потоки есть - Ваши, а есть не ваши, но они ЕСТЬ, и сделали их Вы, НО при этом Вы не видите (по крайней мере сразу) что это Вы их породили.
Если учитывать, что это Мы с помощью мышечной силы включили компьютер, то и потоки, получается, породили на Свет Мы. Увидеть потоки невооруженным глазом, действительно, сложно.
3) cmd.exe или bat файл в режиме MS-DOS - такой-же поток и если Вы думаете, что он одинаков под разными операционками - то Вы ОШИБАЕТЕСЬ. =>
bat файл - поток...
Представляю медлено перетекающий bat-файл...
Легкая рябь на его поверхности, крики чаек...
Успокаивает...
4) Ждать ожидания конца потока (процесса) (смотри RSDN) конечно можно и более того НУЖНО. НО кто сказал, что например - запись дискового файла пройдет раньше, чем закончится поток (который Вы отслеживаете) А КЭШ на что.
И действительно, КЭШ на что?
Вот пусть он и ждет ожидания потока (процесса).
Кстати, как ты понимаешь термин "дисковый файл"?
5)Отсюда вывод - пишите эмуляторы процессов - у меня сейчас это правило, никакая документация не даст окончательного ответа на Вашу ситуацию.
А так же пишите эмуляторы эмуляторов процессов...
А эмулятор процесса - это болиже к потоку или процессу? Или это третий магический артефакт?
Ну, хрен с горы, ты куда делся, я уже с работы ухожу, что замолчал, защитник RSDN.
?
Уходишь с работы? Решил сменить род деятельности?
Давай отвечай. Если я из виндовой прграммы стартую через cmd батник, в котором проворачиваю дисковые операциии при взведенном КЭШ и низком приоритете, то что получится? Чего ожидать?
Спокойствие, а то не дай Бог, взведенный КЭШ пальнет. При низком то приоритете, знаешь, как бабахнет.
Чего получиться не представляю даже... Впрочем, как чего еще ожидать...
А то серанул и скрылся, красавец.
Спасибо за комплименты, но извини, ты не в моем вкусе.
:D
P.S. Юпитер, ты злишься? Ты не прав, Юпитер.
Уходишь с работы? Решил сменить род деятельности?
Спокойствие, а то не дай Бог, взведенный КЭШ пальнет. При низком то приоритете, знаешь, как бабахнет.
Чего получиться не представляю даже... Впрочем, как чего еще ожидать...
Спасибо за комплименты, но извини, ты не в моем вкусе.
:D
P.S. Юпитер, ты злишься? Ты не прав, Юпитер.
Чудило, ты ошибся, злиться на тебя:} Проф. менять, мне поздно, я начинал еще с ЯУЗ если ты конечно знаешь, что это такое. В общем, я не отношусь к категории - чтоб последнее слово за мной, но извини, конкретики нет. Один базар. Поэтому дальнейшее обсуждение - ЯК. Подрости немного, научись конкретно разговаривать, тогда поговорим о вкусах:}
Чудило, ты ошибся, злиться на тебя:} Проф. менять, мне поздно, я начинал еще с ЯУЗ если ты конечно знаешь, что это такое.
Знаю. И не вижу в этом ничего выдающегося.
Ты считаешь, что владение "Языком Управления Заданиями" дает право постулировать бред, а потом "переходить на личности", вместо отстаивания правоты своих суждений?
Ну чтож, раз профессию менять поздно, значит ИТ в опасности...
В общем, я не отношусь к категории - чтоб последнее слово за мной, но извини, конкретики нет. Один базар. Поэтому дальнейшее обсуждение - ЯК. Подрости немного, научись конкретно разговаривать, тогда поговорим о вкусах:}
Вот именно, один базар.
Ты бы прошелся по пунктам своего священного писания и объяснил, чего сказать то хотел. Научил бы меня уму разуму...
А так получается: "Есть два мнения: одно - мое, другое - неправильное, т.к. я с ЯУЗа начинал!"
Ребят, хватит уже, миритесь. Вот название топика - "Вопрос по TThread и RTL".
Да что за день такой - с утра посрался с домашними, пришел на работу, а там шум-гам стоит - все срутся. Потом было совещание. Лучше б его небыло, все пересрались и ничего не решили. А теперь - последняя отдушина - захожу в любимый форум, а здесь тоже срутся.
Ребят, хватит уже, миритесь. Вот название топика - "Вопрос по TThread и RTL".
Прав ты SLA, сраться нам не к лицу... :)
Но, веришь, задевает, когда кто-то тоном наставника лепит полную чушь, вводя в еще большее непонимание начинаюших программеров, а на объективную критику начинает хамить и рассказывать, как он крут. При этом ничего по сути не сказав, поджав хвост вообще исчезает.
Видимо теперь я так и не узнаю, что такое "эмулятор процесса" и что же произошло с "взведенным КЭШем"...
В многопоточном приложении стартовал чужой батник, который должен был создать дисковый файл, который потом нужно затягивать. Ожидание конца процесса (батника) не помогало, редко, но получал битую информацию. При просмотре созданного файла – все в порядке. Отписал свою программку имитирующую эту ситуацию и в результате стал ориентироваться на длину файла, проблемы исчезли.
Ну и какая связь между этим твоим методом (операция на гланды через анус) и просветительской деятельностью в области потоков и процессов?
Видимо, ты настолько запутался в собственных мыслях и домыслах, что не в состоянии сказать что-либо вразумительное. Поэтому попробую задать четкие вопросы, чтоб получить четкие ответы:
1. Что такое процесс, что такое поток и чем они отличаются? Хотелось бы четкое определение, как на уроке геометрии.
2.1 Как это потоки могут быть мои или не мои?
2.2 Как я могу сделать не мой поток?
2.3 Как я могу породить поток и не заметить этого?
3.1 Как файл bat может быть потоком?
3.2 Как файл cmd.exe может быть потоком?
3.3 Что за режим такой MS-DOS ?
3.4 "такой-же" это какой?
3.5 "что он одинаков под разными операционками" - это о чем, что подразумевалось под "одинаков" и "разными операционками" ?
4.1 Что такое дисковый файл?
4.2 А чем КЭШ помешал?
4.3 А разве после работы с файлом не надо закрывать его handle?
4.4 А при закрытии handle не происходит flush?
4.5 А разве обычно пишеться в КЭШ, а читается мимо КЭШа?
5. Что такое "эмуляторы процессов"?
"Если я из виндовой прграммы стартую через cmd батник, в котором проворачиваю дисковые операциии"
А это похоже на извращение, извиняюсь за выражение. Что-то одно, запускает что-то другое, чтоб то запустило что-то третье...
Вырезка из статьи, непомню где взял. Если интересно могу всю выложить.....
Программа, выполняющая несколько действий одновременно, создает объекты, которые называются потоками или нитями (threads).
Когда приложение выполняется, оно загружено в память, готовую к выполнению. В этой точке оно становится процессом, содержащим один или более потоков, которые содержат данные, код и другие системные ресурсы для программы.
Поток выполняет одну часть приложения и ему выделяется процессорное время операционной системой.
Все потоки процесса совместно используют то же самое адресное пространство и могут обратиться к глобальным переменным процесса, т.е. все потоки одного процесса имеют совместный доступ к его ресурсам. Каждый процесс представляет собой один начальный поток, который называется первичным потоком
Первичный поток может создавать вторичные потоки. Операционная система отслеживает список всех потоков и циклически переключается между ними, выделяя каждому потоку часть времени центрального процессора. По завершении времени, выделенного определенному потоку, система запоминает текущее состояние регистров ЦП и ссылку на команду, которая должна была выполниться следующей в данном потоке. Затем система выбирает другой поток, восстанавливает зафиксированное для него состояние регистров ЦП и продолжает выполнение с той команды, на которой оно было приостановлено в прошлый раз.
То есть, в случае организации различных потоков в нескольких точках, программа будет выполняться в нескольких местах одновременно. Когда следует создавать дополнительные потоки ?
• управление вводом от нескольких устройств.
• для различение среди задач изменения приоритета. Например, высоко-приоритетный поток обрабатывает критические по времени задачи, и низко-приоритетный поток исполняет другие задачи.
• для приложений с многодокументным интерфейсом (MDI) потоки для дочерних окон
• если система, выполняющая вашу программу многопроцессорная, Вы можете улучшить работу, деля работу в несколько потоков и позволяя им выполняться одновременно на отдельных процессорах.
Учтите: не все операционные системы осуществляют истинную многопроцессорную обработку, даже когда это поддерживается используемым оборудованием. Например, Windows 9x только моделирует многопроцессорную обработку, даже если используемое оборудование поддерживает это !
Программа, выполняющая несколько действий одновременно, создает объекты, которые называются потоками или нитями (threads).
Когда приложение выполняется, оно загружено в память, готовую к выполнению. В этой точке оно становится процессом, содержащим один или более потоков, которые содержат данные, код и другие системные ресурсы для программы.
Поток выполняет одну часть приложения и ему выделяется процессорное время операционной системой.
Все потоки процесса совместно используют то же самое адресное пространство и могут обратиться к глобальным переменным процесса, т.е. все потоки одного процесса имеют совместный доступ к его ресурсам. Каждый процесс представляет собой один начальный поток, который называется первичным потоком
Первичный поток может создавать вторичные потоки. Операционная система отслеживает список всех потоков и циклически переключается между ними, выделяя каждому потоку часть времени центрального процессора. По завершении времени, выделенного определенному потоку, система запоминает текущее состояние регистров ЦП и ссылку на команду, которая должна была выполниться следующей в данном потоке. Затем система выбирает другой поток, восстанавливает зафиксированное для него состояние регистров ЦП и продолжает выполнение с той команды, на которой оно было приостановлено в прошлый раз.
То есть, в случае организации различных потоков в нескольких точках, программа будет выполняться в нескольких местах одновременно. Когда следует создавать дополнительные потоки ?
• управление вводом от нескольких устройств.
• для различение среди задач изменения приоритета. Например, высоко-приоритетный поток обрабатывает критические по времени задачи, и низко-приоритетный поток исполняет другие задачи.
• для приложений с многодокументным интерфейсом (MDI) потоки для дочерних окон
• если система, выполняющая вашу программу многопроцессорная, Вы можете улучшить работу, деля работу в несколько потоков и позволяя им выполняться одновременно на отдельных процессорах.
Учтите: не все операционные системы осуществляют истинную многопроцессорную обработку, даже когда это поддерживается используемым оборудованием. Например, Windows 9x только моделирует многопроцессорную обработку, даже если используемое оборудование поддерживает это !
Спасибо, Тимофей, что вмешался в наш "спор с элементами мордобоя".
И так, в кратце получаем:
1. Процесс - владелец ресурсов, в т.ч. и потоков. Сам по себе процесс ничего не делает, несмотря на свое название, а лишь владеет.
Программа же выполняется потоком или потоками.
Это трактовка по Мэтту Питреку.
2. Потоки не могут быть вашими, нашими. Потоки создаются в контексте реально существующего процесса потоками этого же или другого существующего процесса. Сл-но для того, чтобы возник поток, в другом потоке должна быть выполнена определенная последовательность действий, т.е. сами потоки не возникают.
3. Файл ну никак не может быть потоком. Приложение загружается в память загрузчиком и загрузчик же создает первичный поток, т.о. исполняемый файл ассоциируется скорее с процессом, чем с потоком. Файл bat не является приложением вовсе. Он интерпретируется командным процессором, - процессом созданным при запуске cmd.exe (command.exe) и т.п.
4. Все операции ввода/вывода, действительно, кешируются, но в большинстве случаев это не мешает, а только помогает. В вышеуказанном магическом случае с "чужим батником" проблема скорее не в кеше, а в неправильной синхронизации, в силу неполного осмысления основ многопоточности, многопроцессности, а так же принципов работы командного процессора. Отслеживать надо было не окончания процесса батника (я вообще не представляю, как такое возможно) и даже не окончания работы командного процессора, обрабатывающего этот "батник", а отследить надо было окончание всех процессов порожденных в процессе обработки скриптового bat-файла. Понятно, что такая слежка трудоемка, а сам механизм с "чужим батником" нецелесообразен.
Мне не понятно, зачем вообще были нужны такие сложности? Если "чужой батник" неизменен, то почему бы его (точнее последовательность его действий) не реализовать в собственном коде? Если "чужой батник" изменяется, то каким образом оставалась неизменной длина результирующего файла? Да и нельзя ли было найти более рациональный способ передачи последовательностей операций? Ну на крайний случай более гибкие в управлении и сопряжении скриптовые интерпритаторы JScript или VBScript?
Жаль, что автор постулатов, так и не объяснился.
Ничего сложного, но надо же было это извратить до неузнаваемости (посмотрите второе сообщение темы).
Ну а где бред, где - нет, решайте сами.
А вот что такое "эмуляторы процессов" для меня так и осталось загадкой.
P.S. Vlad232ua, Вам бы еще поучиться инженерной и человеческой этике, несмотря на Ваш преклонный возраст. Вечно Ваш, тринадцатилетний (Вы же таким меня представляете?) ХаЦкЕр, хрен с горы и просто красавец, Green.