Dll и TThread

← →
Добрый дядька © (2004-10-29 16:46) [120]

>dms_main © (29.10.04 16:44)

Т.е. ты в точности создал проект с кодом библиотеки и вызовом?

← →
dms_main © (2004-10-29 16:46) [121]

> >Reindeer Moss Eater © (29.10.04 16:40)
>
> И что же ей мешает?
>
> Я думаю, возникающий Exception, в результате чего процесс
> успешно терминируется системой вместе с вновь созданным(или
> не успевшим создаться) потоком.

Странно - никаких исключений и ошибок я не наблюдаю......

← →
Reindeer Moss Eater © (2004-10-29 16:47) [122]

Добрый дядька ©

Он в IDE его отлаживает если помнишь.

← →
dms_main © (2004-10-29 16:48) [123]

> Добрый дядька - нет исправил свой в точности с указаниями
(зачем смысл то тотже)

← →
Добрый дядька © (2004-10-29 16:50) [124]

>dms_main © (29.10.04 16:48)
(зачем смысл то тотже)

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

← →
dms_main © (2004-10-29 16:50) [125]

Мастера - насчет отладки - в execute создается файл - нету этого файла - несоздается он > execute не выполняется.

← →
dms_main © (2004-10-29 16:51) [126]

В console Application тотже код работает без проблем.

← →
Reindeer Moss Eater © (2004-10-29 16:54) [127]

Парень, сколько раз можно повторять, что у тебя не создается экземпляр, потому и нет execute.

А в отладчике есть создание потому что IDE загружает библиотеку первая.

← →
dms_main © (2004-10-29 16:57) [128]

> Reindeer Moss Eater © (29.10.04 16:54) [127]
> Парень, сколько раз можно повторять, что у тебя не создается
> экземпляр, потому и нет execute.
>
> А в отладчике есть создание потому что IDE загружает библиотеку
> первая.

ok - тоесть без экспорта работать небудет?(файла то создаваемого нет)

← →
Digitman © (2004-10-29 16:59) [129]

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

т.е. Execute-то как раз выполняется, но вот из-за глюка дебаггер не может отработать брэйкпойнт в теле поточной ф-ции

но даже если так, то MessageBox (ПЕРВОЙ же строчкой после begin в Execute) обязан зафиксировать факт успешного старта поточной ф-ции... если, конечно же, не умудриться напортачить еще и с параметрами MessageBox..

← →
dms_main © (2004-10-29 17:04) [130]

> Digitman ©
винда ХР со всеми патчами,D7 без мудрежа дэббагит,
нету ни файла ни месседж бокса ни меесадж бипа.

← →
Digitman © (2004-10-29 17:09) [131]

> dms_main © (29.10.04 17:04) [130]

да ну не верю я !

ты что-то существенное скрываешь, то что упорно не приводишь в примерах своего кода ..

почему ты до сих пор не оттрассировал пошагово тело конструктора TThread ?

← →
dms_main © (2004-10-29 17:15) [132]

вот те другой мой код в котором таже беда - невижу смысла выкладывать 14к кода если в 0,7к таже беда:
library finer_lib; uses SysUtils,windows, Classes; type TMyThread = class (TThread) a:integer; b:integer; c:integer; constructor create(a0,b0:integer); destructor free; procedure execute;override; end; constructor TMyThread.create(a0,b0:integer); begin inherited create(true); a:=a0; b:=b0; // FreeOnTerminate:=true; resume; end; destructor TMyThread.free; begin inherited free; end; procedure TMyThread.execute; var t:TstringList; begin c:=a*b; t:=TStringList.Create; t.Add("Result = "+inttostr(c)); t.SaveToFile("c:\result.nfo"); t.Free; end; {$R *.RES} var thread:TMyThread; begin delete thread:=TMyThread.create(2,2); thread.WaitFor; end.

← →
Добрый дядька © (2004-10-29 17:16) [133]

Так тоже дебаггер не заходит в поточную функцию?

library ThrDll; uses windows; type TParm=record X,Y: Integer; end; var Parm: TParm; ThreadId: THandle; procedure ThreadFunc(aParm: Pointer); cdecl; var i: Integer; begin for i := 0 to TParm(aParm^).X do begin Write("Test"+#13#10); end; end; begin Parm.X := 2; Parm.Y := 2; CreateThread(nil,0,@ThreadFunc,@Parm,0,ThreadId); end.

← →
Reindeer Moss Eater © (2004-10-29 17:18) [134]

Код приглашенного актера прекрасно работает в консольном приложении (читай - в однопоточном) - давайте верить в это.

В многопоточном не работает как надо. - давайте тоже верить в это.

Значит где трабл зарыт?
Правильно. В особенности парочки DLL + вторичный поток.

Не понимаю, как можно в течении 130 постов обсуждать очевидное.

← →
dms_main © (2004-10-29 17:18) [135]

Добрый дядька © >
это - совершенно другая песня здесь заходит.

← →
Digitman © (2004-10-29 17:19) [136]

> dms_main © (29.10.04 17:15) [132]

и долго ты еще будешь постить сюда один и тот же код в разных вариациях ?

я тебе вопрос задал - ЧТО показала пошаговая трассировка TThread.Create() ?

← →
dms_main © (2004-10-29 17:20) [137]

Reindeer Moss Eater © > несогласен только с одним - "приглашенный актер" интересно это к чему? :-(

← →
Reindeer Moss Eater © (2004-10-29 17:21) [138]

ЧТО показала пошаговая трассировка TThread.Create() ?

Ничего полезного она не покажет.

Отладчик туда зайдет, потому что либа бкдет все же загружена.
Но вторичный поток загрузив либу, не заставит отладчик зайти туда.

← →
dms_main © (2004-10-29 17:21) [139]

> Digitman ©

весь код который в create выполнился, в execute не заходит.

← →
Reindeer Moss Eater © (2004-10-29 17:24) [140]

Reindeer Moss Eater © > несогласен только с одним - "приглашенный актер" интересно это к чему? :-(

Потому что программер на форуме решает реальные проблемы, а приглашенный актер играет роль.

← →
Digitman © (2004-10-29 17:25) [141]

> Reindeer Moss Eater © (29.10.04 17:18) [134]

что-то я тебя не понял ..
какая разница, откуда будет вызвана в дан.случае LoadLibrary - из основного или доп.трэда хост-процесса ? та же CreateThread в конечном итоге вызывается, что мешает ее успешному выполнению, даже если вызвана она из доп.трэда ?

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

или ты намекаешь на то, что до CreateThread даже дело не доходит ? но в Д5, по кр.мере, обязано доходить !

← →
dms_main © (2004-10-29 17:26) [142]

> Reindeer Moss Eater ©

то есть получается я от нефиг делать тут весь день торчу ? :-(

> Потому что программер на форуме решает реальные проблемы

и трабла моя вымышлена?

← →
Reindeer Moss Eater © (2004-10-29 17:28) [143]

Разница такая.

Мы ставим BP.
И мы попадем на эту BP.
Но это не та нить, которую мы отлаживаем.

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

Точка останова есть, и мы туда попадаем.
Но только не тогда, когда вторичный поток делает LoadLobrary

← →
dms_main © (2004-10-29 17:30) [144]

> Но только не тогда, когда вторичный поток делает LoadLobrary

Я это все давно понял - можно не повторяться.
Лечиться это или нет - вот в чем вопрос.

← →
dms_main © (2004-10-29 17:30) [145]

← →
Reindeer Moss Eater © (2004-10-29 17:32) [146]

Лечиться это или нет - вот в чем вопрос.

Устал я. Домой иду.

← →
Digitman © (2004-10-29 17:35) [147]

> Reindeer Moss Eater © (29.10.04 17:21) [138]

с какой стати отладчик автоматом загрузит ДЛЛ, если она в хост-приложении грузится искл-но динамически ? и если никаких Reload Symbol Table и иже с ним сомнительных фич не задействовать явно ?

← →
Добрый дядька © (2004-10-29 17:37) [148]

>dms_main © (29.10.04 17:30)
WAitFor убери. Совсем.

с какой стати отладчик автоматом загрузит ДЛЛ, если она в хост-приложении грузится искл-но динамически ?
Динамически. Да.
Но не из единственного потока.

какая разница, откуда будет вызвана в дан.случае LoadLibrary - из основного или доп.трэда хост-процесса ?

Никакой разницы нет. Можно из основного, можно из вторичного.

Разница есть какой поток делает это первым в процессе.

Потому что у него код создания потока, создающего файлы привязан к блоку begin/end библиотеки.

А блок этот вызывается один раз за весть процесс сколько бы ни вызывали LoadLibrary в этом процессе.

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

И вообще не понятно, откуда берутся параметры для конструктора того потока, если его запуск заточен под автоматическое выполнение кода между begin/end библиотеки при простой загрузке библиотеки.

Получается, что они вообще хардкодед.

Ну и развели..

Надо было сказать:

> Лечиться это или нет - вот в чем вопрос.

Лечится только в военном госпитале.

Что бы "работало" без экспорта

library lib;

uses Windows;
{$R *.res}

procedure DllProcedure(AReason : integer);
begin
case AReason of
DLL_PROCESS_ATTACH,
DLL_THREAD_ATTACH : begin
//Создание экземпляров TThread
....
end;
DLL_PROCESS_DETACH :;
DLL_THREAD_DETACH :;
end;
end;

begin
DllProc := DllProcedure;
DllProc(DLL_PROCESS_ATTACH);
end.

> Reindeer Moss Eater © (29.10.04 17:41) [149]

DLL_THREAD_ATTACH здесь к делу никоим образом не относится

как только любой трэд процесса в самый первый раз будет грузить ДЛЛ (явно или неявно), системой будет вызвана DllEntryPoint(DLL_PROCESS_ATTACH), что в конечном счете должно привести к передаче управления в блок begin..end библиотеки, где у автора вызывается конструктор TMyThread.Create (он и вызывается в действительности - автор это подтверждает) .. если в ходе работы конструктора не возникло исключений, то поточная ф-ция обязана стартовать и вызвать при этом Execute, и брейкпойнт в самом начале тела Execute ну просто обязан быть пойманным отладчиком ..

Балин...
Любите хелп -- источник знаний:

During process startup and DLL initialization routines, new threads can be created, but they do not begin execution until DLL initialization is done for the process.

Он (автор) хочет, что бы бегин/енд выполнялся при LoadLibrary из любого потока хост приложения.

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

DiamondShark ©

Любите источник знаний целиком и до конца.
Все это касается статического импорта библиотеки.
Если импорт динамический, то вторичному потоку ничто не помешает ни выполняться, ни самому грузить dll первее главного треда

> Reindeer Moss Eater © (01.11.04 12:43) [155]

я ОДНОГО не понял - автор утверждает, что ВР в теле Execute он ВООБЩЕ не ловит в ходе самого первого обращения к ДЛЛ ... хотя тело конструктора хотя бы однократно получает управление ...

этого быть не может - рано или поздно поточная ф-ция все равно стартует

> DiamondShark © (01.11.04 12:41) [154]

ну и что ? рано или поздно ВР должна сработать !

> Reindeer Moss Eater © (01.11.04 12:57) [156]

Это ты к чему?

> Digitman © (01.11.04 12:57) [157]
> ну и что ? рано или поздно ВР должна сработать !

Не-а. У него там WaitFor стоит.

Объясняю.

Вызываем LoadLidrary, LoadLidrary не возвращается, пока не отработает DLL entry point.
В DLL entry point создаётся поток, который будет подвешен, пока не завершится DLL entry point.
К контексте DLL entry point вызывается поток.WaitFor, которая не вернётся, пока не закончится поток, который не запустится пока не закончится DLL entry point, которая не закончится пока не вернётся WaitFor... в доме который построил Джек.

Если убрать WaitFor, то поток начнёт работь сразу, как вернётся DLL entry point. Тут, правда автором заботливо подложены другие грабли в виде FreeLibrary сразу после LoadLibrary.

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

Проблема XP-DLL-отладчик известная (хоть в однопоточном, хоть в многопоточном приложении). По какой-то причине отладчик не подгружает отладочную символьную информацию из DLL и поэтому брейкпойнты в DLL не срабатывают (хотя код работает). Лечится это либо установкой эксперта IDE (встречал в сети, но где - не помню), либо так.

1. В DLL сразу после главного begin пишем любой MesssageBox -что угодно, лишь бы тормознуть программу.

2. Когда этот MessageBox появится, переключаемся в Delphi, жмем Ctrl-Alt-M, в появившемся окне (слева внизу) находим свою DLL, жмакаем по ней правой кнопкой мыши и выбираем Reload Symbol Table. Если все прошло ОК, то справа увидим, что отладочная информация подгрузилась.

3. В MessageBox жмем OK - теперь брейкпойнты должны работать.

Dll и TThread Найти похожие ветки