Конференция "Прочее" » Многопоточность и Delphi
 
  • Сергей М. © (25.04.08 11:25) [20]

    > // Ошибок нет


    "Ты суслика видишь ? И я не вижу. А он есть !"  (с)


    > // Ожидаем завершения потока


    Это вовсе не ожидание завершения потока, а всего лишь ожидание момента когда переменная Term примет значение False.


    > Sleep(0); // AV валятся здесь


    Именно здесь AV валиться не может, не выдумывай.
    Неоткуда тут AV взяться.
  • guav © (25.04.08 11:28) [21]
    > BeginThread(nil, 0, @MyThreadFunc, 0, 0, I); // Ошибка есть

    Ошибка в твоём коде.
  • Loginov Dmitry © (25.04.08 11:29) [22]

    > Именно здесь AV валиться не может, не выдумывай.
    > Неоткуда тут AV взяться.


    Я ведь когда-то тоже так думал! А оказывается, что есть откуда.
    И именно на Sleep(0)...
  • Loginov Dmitry © (25.04.08 11:29) [23]

    > Ошибка в твоём коде.


    Где именно?
  • Сергей М. © (25.04.08 11:30) [24]

    > BeginThread(nil, 0, @MyThreadFunc, 0, 0, I); // Ошибка есть


    При объявлении MyThreadFunc ты указал соглашение stdcall  - вот граблями и получил)
  • guav © (25.04.08 11:31) [25]
    Смотри что передаёшь в BeginThread и что она требует.
  • guav © (25.04.08 11:31) [26]
    Кстати, если писать такое без @, то компилятор будет проверять прототип.
  • Сергей М. © (25.04.08 11:32) [27]

    > именно на Sleep(0)


    То, что остановившись на этой строчке по брейкпойнту ты жмакнул F7 и получил AV, вовсе не означает, что именно эта строчка является причиной исключения.
  • Loginov Dmitry © (25.04.08 11:42) [28]
    Мда... Неудачный получился пример. Сорри за невнимательность :(
    Но один фик с TThread AV гарантированно лезут...
  • Сергей М. © (25.04.08 11:44) [29]

    > один фик с TThread AV гарантированно лезут


    Иллюстрируй в коде теперь с TThread..
  • Loginov Dmitry © (25.04.08 11:55) [30]

    > Иллюстрируй в коде теперь с TThread..



    unit DllUnit;

    interface

    uses
     Windows, Messages, SysUtils, Variants, Classes;

    type
     TMyThread = class(TThread)
     protected
       procedure Execute; override;
     end;  

    implementation

    var
     MyThread: TMyThread;

    procedure StartMythread;
    begin
     MyThread := TMyThread.Create(False);
    end;

    { TMyThread }

    procedure TMyThread.Execute;
    begin
     inherited;
     //FreeOnTerminate := True; // Не влияет
     while not Terminated do
       Sleep(50);
    end;

    initialization
     StartMythread;
    finalization
     // сценарий 1
     //MyThread.Terminate; // возникает AV

     // сценарий 2
     //MyThread.Free; // Программа зависает

     // сценарий 3
     //MyThread.Terminate; // Программа
     //MyThread.WaitFor;   // зависает

     // сценарий 4
     // Ничего не делаем - возникает AV
    end.



    Опять ведь найдете че-нибудь.... :)
  • Сергей М. © (25.04.08 12:00) [31]

    > Loginov Dmitry ©   (25.04.08 11:55) [30]


    1,4 - ничего удивительного, абсолютно ожидаемый результат.
    2,3 - см. [7] на предмет причины зависания
  • Loginov Dmitry © (25.04.08 12:13) [32]

    > 1,4 - ничего удивительного, абсолютно ожидаемый результат.
    >
    > 2,3 - см. [7] на предмет причины зависания


    Да насчет зависаний как раз-то все и понятно. Windows SDK об этом говорит вполне четко.

    Таким образом получается, что в любом случае мы ловим или AV, или зависание.
    А можно ли это как-то обойти без дополнительной экспортируемой функции? И как?
  • Сергей М. © (25.04.08 12:39) [33]

    > Loginov Dmitry ©   (25.04.08 12:13) [32]
    >
    >


    Обойти в принципе можно, но реализация обхода будет уже из разряда трюков.
    А трюки, как известно, штука рискованая и ненадежная)
  • Loginov Dmitry © (25.04.08 12:52) [34]
    кстати, в finalization такой трюк обычно спасает:


     MyThread.Terminate;
     while Assigned(MyThread) do
       Sleep(20);



    Но не всегда. В случае, когда FreeLibrary библиотеке не делают, при завершении работы процесса все-равно вызывается для всех DLL finalization, но к этому моменту винда уже успевает срубить все потоки, поэтому данный код приводит лишь к зависанию.
  • Сергей М. © (25.04.08 12:58) [35]

    > такой трюк обычно спасает


    С какого перепугу ?
  • Пробегал2... (25.04.08 13:40) [36]
    Игорь Шевченко ©   (25.04.08 9:42) [16]
    Какая разница, где завершать потоки (потоки Windows, а не Delphiйские TThread) ?


    а зачем в дельфи лишать себя такого удобного класса, как TThread?
  • Loginov Dmitry © (25.04.08 13:40) [37]

    > С какого перепугу ?


    В конце TMyThread.Execute (или в деструкторе) выполняется присвоение MyThread := nil
  • Игорь Шевченко © (25.04.08 14:01) [38]
    Пробегал2...   (25.04.08 13:40) [36]

    Тут в ветке где-то про чтение Рихтера говорили. Нафига читать Рихтера, если он в Delphi ни ухом ни рылом ?
  • Сергей М. © (25.04.08 15:16) [39]

    > Loginov Dmitry ©   (25.04.08 13:40) [37]


    > В конце TMyThread.Execute (или в деструкторе) выполняется
    > присвоение MyThread := nil
    >


    И что ?

    Появление какой-то там nil в какой-то там переменной не есть факт завершения поточной функции.

    Это те же фаберже, чт о и в [19], только вид сбоку)

    Ты, видимо, совершенно не понимаешь, что является главным признаком фактического завершения исполнения поточной функции.
 
Конференция "Прочее" » Многопоточность и Delphi
Есть новые Нет новых   [134435   +34][b:0][p:0.001]