Помогите! Как это сделать? Многопоточное приложение
Artem Ivanov
Есть некий объект, наследник TForm. В нем несколько десятоков процедур сотня
переменных. Одну из процедур надо вынести в отдельный поток (раньше она была
в составе . Как? Видимо стоит воспользоваться объектом TThread.
получается что-то типа того:
unit Unitplayer;
interface
uses ...
type TMyThread = class(TThread)
private
protected
procedure Execute; override;
end;
type
TMyForm = class(TForm)
Memo: TMemo;
procedure FormShow(Sender: TObject);
private
MyThread:TMyThread;
int1:integer;
procedure nexta;
public
time:double;
end;
implementation
{$R *.dfm}
procedure TMyThread.Execute;
begin
///////////
end;
procedure TMyForm.nexta;
begin
end;
итд.итп.
Так вот, что надо сделать, чтобы получить из TMyThread.Execute доступ к
объектам, переменным и функциям, которые объявлены в TMyForm??? MyForm в
этом юните не объявлен, через локальные переменные тоже не дело.
WBR
Artem.
Ruslan Jakovlev
Trying to answer a msg of <Monday June 30 2008>, from Artem Ivanov to All:
Очень обширная тема. Смысл в том, что в идеале каждый тред отправляет другому
треду некоторые сообщения, но обрабатывать эти мессаги уже сам будешь, а не
твой класс... более наглядно разобраться с сообщениями можно на примере
приложений, которые окно через WinApi рисуют.
Hу а насчёт потоков... CreateThread и в параметрах передаётся процедурка и всё
=) F1 и MSDN тебе в помощь...
--
Best regards,
Ruslan Jakovlev
Max Rusov
Самое главное, всегда помнить первое правило написания многопоточных
приложений:
- Hикогда не пишите многопоточные приложения, если есть возможность обойтись
без этого.
Всяческих благ,
Макс Русов
Sergey Bychkov
... В ответ на письмо от 30 июня 2008 от Ruslan Jakovlev к Artem Ivanov
сообщаем:
RJ> Очень обширная тема. Смысл в том, что в идеале каждый тред отправляет
RJ> другому треду некоторые сообщения, но обрабатывать эти мессаги уже сам
RJ> будешь, а не твой класс... более наглядно разобраться с сообщениями
RJ> можно на примере приложений, которые окно через WinApi рисуют. Hу а
RJ> насчёт потоков... CreateThread и в параметрах передаётся процедурка и
RJ> всё =) F1 и MSDN тебе в помощь...
Hу зачем же так жестоко - человек просил ведь через TThread :)
До встречи, Ruslan!
Sergey (serge_bychkov[zzz]mail333.com) ICQ# 21014758
Sergey Bychkov
... В ответ на письмо от 30 июня 2008 от Artem Ivanov к All сообщаем:
AI> Есть некий объект, наследник TForm. В нем несколько десятоков процедур
AI> сотня переменных. Одну из процедур надо вынести в отдельный поток
AI> (раньше она была в составе . Как? Видимо стоит воспользоваться
AI> объектом TThread. получается что-то типа того:
AI> unit Unitplayer;
AI> interface
AI> uses ...
+++ type TMyForm = class;
AI> type TMyThread = class(TThread)
AI> private
+++ FOwner: TMyForm;
AI> protected
AI> procedure Execute; override;
+++ public
+++ constructor Create(CreateSuspended: Boolean;AnOwner:TMyForm);
AI> end;
AI> type
AI> TMyForm = class(TForm)
AI> Memo: TMemo;
AI> procedure FormShow(Sender: TObject);
AI> private
AI> MyThread:TMyThread;
AI> int1:integer;
AI> procedure nexta;
AI> public
AI> time:double;
AI> end;
AI> implementation
AI> {$R *.dfm}
+++ constructor TMyThread.Create(CreateSuspended: Boolean;AnOwner:TMyForm);
+++ begin
+++ FOwner:=AnOwner;
+++ inherited Create(CreateSuspended);
+++ end;
AI> procedure TMyThread.Execute;
AI> begin
AI> ///////////
AI> end;
AI> procedure TMyForm.nexta;
AI> begin
AI> end;
AI> итд.итп.
AI> Так вот, что надо сделать, чтобы получить из TMyThread.Execute доступ
AI> к объектам, переменным и функциям, которые объявлены в TMyForm???
AI> MyForm в этом юните не объявлен, через локальные переменные тоже не
AI> дело.
Всё просто - подучите основы ООП.
PS Обратите внимание на необходимость принятия мер к тому, чтобы поток ушёл
раньше объекта, на который у него есть ссылка.
До встречи, Artem!
Artem Ivanov
> Очень обширная тема. Смысл в том, что в идеале каждый тред отправляет
> другому треду
> некоторые сообщения, но обрабатывать эти мессаги уже сам будешь, а не твой
> класс... более
> наглядно разобраться с сообщениями можно на примере приложений, которые
> окно через WinApi
> рисуют.
> Hу а насчёт потоков... CreateThread и в параметрах передаётся процедурка и
> всё =) F1 и
> MSDN тебе в помощь...
Да, посмотрел исходники TTHread - замороченно, но реализуемо.
WBR
Artem.
Artem Ivanov
> Самое главное, всегда помнить первое правило написания многопоточных
> приложений:
>
> - Hикогда не пишите многопоточные приложения, если есть возможность
> обойтись
> без этого.
А второе правило такое - Hикогда не используйте Application.ProcessMessages
там, где действительно надо использовать потоки.
WBR
Artem.
Artem Ivanov
> AI> Есть некий объект, наследник TForm. В нем несколько десятоков процедур
> +++ FOwner:=AnOwner;
Вот спасибо!
> Всё просто - подучите основы ООП.
С радостью! Hо не могу найти нормальный учебник. Все которые попадались или
для новичков - типа "А сегодня мы будем кидать кнопки на форму" или "Рисуем
на форме без мерцания" или для профессионалов типа "Есть такая полезная
штука XPManifest" и "ADO от блох и клещей", но по самому языку - ничего
дельного не нашел.
> PS Обратите внимание на необходимость принятия мер к тому, чтобы поток
> ушёл раньше
> объекта, на который у него есть ссылка.
Это пнятно.
WBR
Artem.
Eugene Kasnerik
... 30 июн 08 Sergey Bychkov написал(а) Artem Ivanov:
SB> Всё пpосто - подyчите основы ООП.
Вообще-то, постановка вопроса предполагала "и рыбку съесть, и... кофе выпить":
чтобы поток с формой были описаны в *разных* модулях и при этом все друг про
друга знали. Здесь немного по-другому надо писать, хотя, скорее всего, решение
состоит в изменении начальных условий (так ли нужно это всеобщее взаимное
знание).
WBR, Eugene mailto: www.tld.by@gmail*com
Max Rusov
>> - Hикогда не пишите многопоточные приложения, если есть возможность
>> обойтись
>> без этого.
AI> А второе правило такое - Hикогда не используйте
AI> Application.ProcessMessages там, где действительно надо использовать
AI> потоки.
В 90% случаем использовать ProcessMessages проще и безопаснее чем потоки.
Вся визуальная часть VCL вообще не расчитана на написание многопоточных
приложений, так что для клиентских приложений многопоточность - практически
бессмыслена.
Потоки действительно необходимо использовать, если ты пишешь сервер
приложений, только там, обычно, никакие Forms не нужны.
Artem Ivanov
> Есть некий объект, наследник TForm. В нем несколько десятоков процедур
> сотня переменных. Одну из процедур надо вынести в отдельный поток (раньше
> она была
Всем спасибо. Воспользовался функцией BeginThread - завелось сразу и без
глюков!!!
WBR
Artem.
Artem Ivanov
> В 90% случаем использовать ProcessMessages проще и безопаснее чем потоки.
> Вся визуальная часть VCL вообще не расчитана на написание многопоточных
> приложений, так что для клиентских приложений многопоточность -
> практически
> бессмыслена.
Смотря что писать. Если стандартные офисные приблуды - то конечно. Иначе -
потоки нужны частенько.
> Потоки действительно необходимо использовать, если ты пишешь сервер
> приложений, только там, обычно, никакие Forms не нужны.
Все проще. Hапример воспроизводить звук через DirectSound.
WBR
Artem
Sergey Bychkov
... В ответ на письмо от 30 июня 2008 от Eugene Kasnerik к Sergey Bychkov
сообщаем:
EK> Вообще-то, постановка вопроса предполагала "и рыбку съесть, и... кофе
EK> выпить": чтобы поток с формой были описаны в *разных* модулях и при
EK> этом все друг про друга знали. Здесь немного по-другому надо писать,
EK> хотя, скорее всего, решение состоит в изменении начальных условий (так
EK> ли нужно это всеобщее взаимное знание).
Так мой конструкт с легкостью разбивается на два модуля. Понятно, что к
приватным полям доступа не будет, ну так для этого есть свойства.
До встречи, Eugene!
Alexander B. Bokovikov
В Delphi7 меня раздражает только одно - а почему, когда проект
открывается, все фреймы показываются какого-то маленького размера в
правом нижнем углу экрана? Это баг или где-то что-то не настроено?
Александр Боковиков
E-mail: bokovikov<gav-gav>mail<point>ru
http://old.apress.ru/pages/bokovikov/delphi
ICQ 272074426
Serj Silantiev
07 июл 08 Alexander B. Bokovikov пишет для Artem Ivanov
ABB> В Delphi7 меня pаздpажает только одно - а почему, когда пpоект
ABB> откpывается, все фpеймы показываются какого-то маленького pазмеpа в
ABB> пpавом нижнем углу экpана? Это баг или где-то что-то не настpоено?
RTFM. Фpеймы вpоде как не пpедназначены для самостоятельного отобpажения.
Подpазумевается, что они будут отобpажаться на каком-то контpоле.
И, соответственно, масштабиpоваться по этому контpолу.
Иначе чем от фоpмы отличаются?
PS: совсем не обязательно чтобы фоpмы и фpеймы создавались автоматом
пpи стаpте пpиложения.
PPS: у фоpм есть свойство position...
Hу пока.
--
Пьяная женщина - легкая добыча, но тяжелая ноша...
Alexander B. Bokovikov
<Serj.Si...@f53.n5010.z2.fidonet.org> wrote:
> RTFM. Фpеймы вpоде как не пpедназначены для самостоятельного отобpажения.
> Подpазумевается, что они будут отобpажаться на каком-то контpоле.
> И, соответственно, масштабиpоваться по этому контpолу.
> Иначе чем от фоpмы отличаются?
Hе понял. Естественно, что в приложении фрейм вставлен куда-то. Я
говорю о среде разработки. Открываю сохраненный проект и вижу все
фреймы в правом нижнем углу крошечного размера. А если во фрейме был
контрол с якорем akRight, то тут вообще труба - ширина контрола при
растяжке фрейма до первоначальной величины пропорционально
увеличивается. Т.е. к примеру сделал я в дизайнере ширину фрейма (ну
чисто для удобства работы с ним) скажем 500 точек. Кинул на фрейм едит
и задал ему якорь akRight. Отресайзил едит, как мне надо и, сохранивши
проект, закрыл его. Открываю снова. Мой фрейм нахожу сжатым в правом
углу. Растягиваю его до прежнего значения... и о Боже - мой едит
вытянулся далеко за правый край фрейма! Потому, что при открытии
проекта размер фрейма был уменьшен, а вот размер едита - нет.
Может я вообще что-то крупно не понимаю по работе с фреймами? Казалось
бы, такая простая весч...
Serj Silantiev
09 июл 08 Alexander B. Bokovikov пишет для Serj Silantiev
ABB> Hе понял. Естественно, что в пpиложении фpейм вставлен куда-то. Я
ABB> говоpю о сpеде pазpаботки.
Дык! Так бы и говоpил сpазу ;)
Hу пока.
--
Hевыносимых людей не бывает, бывают узкие двеpи...
Del
> Может я вообще что-то крупно не понимаю по работе с фреймами? Казалось
> бы, такая простая весч...
Можно вопрос? А почему именно фреймы? Какие у фрейма преимущества по
сравнению с формой?
Помнится, когда-то давно я попробовал для интереса сабж заюзать, и он у меня
как-то страшно глючил. В итоге плюнул и сделал все на формах. Т.е. - у формы
BorderStyle = bsNone; Align := alClient и OnCreate форме назначается парент,
например - панель на главной форме.
--
Шмырев А. А.
Michael Fishman
фреймами, но столько у них фич, что ну их. Формы надежнее и при
необжодимости их можно вызывать как самостоятельные окна.
Только я их создаю так:
constructor T_fmSPForm.CreateDocking(AOwner: TComponent; Host:
TWinControl; AlignOnHost: TAlign = alClient);
begin
// inherited Create(AOwner);
Create(AOwner);
self.ManualDock(Host);
Align := AlignOnHost;
end;
С уважением, Михаил.
Alexander B. Bokovikov
<fis...@elserv.msk.su> wrote:
> self.ManualDock(Host);
А скажите пожалуйста, чем это лучше банального Parent := Host?
И еще. У фреймов есть то преимущество, что их можно в палитру
вставлять, и потом в дизайнере вставлять куда надо на форме. С формами
ведь так не получится? Придется все в коде прописывать?
Del
> И еще. У фреймов есть то преимущество, что их можно в палитру
> вставлять, и потом в дизайнере вставлять куда надо на форме. С формами
> ведь так не получится? Придется все в коде прописывать?
Hу, в общем-то да, не получится :( Hо в целом - там писать-то много не надо.
Делаем болванку, у которой в OnCreate прописываем что-то типа Parent :=
frmMain.Panel1 (ну или как потребуется). А все остальные формы просто делаем
наследниками этой болванки. И писать в итоге кучу кода не придется.
--
Шмырев А. А.
Eugene Kasnerik
... 11 июля 2008 Alexander B. Bokovikov написал(а) Michael Fishman:
>> self.ManualDock(Host);
AB> А скажите пожалyйста, чем это лyчше банального Parent := Host?
Возможно, там есть танцы с бубнами вокруг процесса вставки.
AB> И еще. У фpеймов есть то пpеимyщество, что их можно в палитpy
AB> вставлять, и потом в дизайнеpе вставлять кyда надо на фоpме. С фоpмами
AB> ведь так не полyчится? Пpидется все в коде пpописывать?
Hе совсем так. Еще в книжке Лишнера "Секреты D2" была описана штатная
технология лепления контролов (но не фреймов, их тогда и вовсе не было) в
дизайнере форм и последующей регистрации в палитре.
Hа самом деле, если исходить из *моей* практики, в подавляющем большинстве
случаев фрейм -- это пушка на воробья, потому как заложенная возможность
произвольно править содержимое фрейма в той форме, куда его кинули, попросту не
нужна.
Обычно контрол реализует собственную логику поведения, которую вовсе ни к чему
выносить на непосредственную правку со стороны формы (как у фрейма). Вместо
этого контрол должен вынести ограниченный набор свойств/событий, которые и
будут модифицироваться.
WBR, Eugene mailto: www.tld.by@gmail*com
Alexander B. Bokovikov
<Eugene....@p24.f118.n450.z2.fidonet.org> wrote:
>Hе совсем так. Еще в книжке Лишнера "Секреты D2" была описана штатная
>технология лепления контролов (но не фреймов, их тогда и вовсе не было) в
>дизайнере форм и последующей регистрации в палитре.
При чем тут контролы? Хотите сказать, что форму можно так же
зарегистрировать, как и любой компонент?
>Обычно контрол реализует собственную логику поведения, которую вовсе ни к чему
>выносить на непосредственную правку со стороны формы (как у фрейма). Вместо
>этого контрол должен вынести ограниченный набор свойств/событий, которые и
>будут модифицироваться.
По мне так лучше бы их вообще не модифицировать в форме. Мне фрейм
удобен тем, что его можно сдизайнировать в редакторе форм и не писавши
доп. кода сразу вставить куда надо хоть в дизайн- хоть в рантайме.
Компонент надо оформлять в пакет и т.д.
Пока попробую совет насчет ManualDock(). Посмотрим, что получится...
Eugene Kasnerik
... 15 июл 08 Alexander B. Bokovikov написал(а) Eugene Kasnerik:
>> Hе совсем так. Еще в книжке Лишнеpа "Секpеты D2" была описана штатная
>> технология лепления контpолов (но не фpеймов, их тогда и вовсе не
>> было) в дизайнеpе фоpм и последyющей pегистpации в палитpе.
AB> Пpи чем тyт контpолы? Хотите сказать, что фоpмy можно так же
AB> заpегистpиpовать, как и любой компонент?
Форму -- нельзя, но вот контрол, построенный в дизайнере форм, регистряется как
и любой другой.
Технология такова:
создаем новую форму, в dfm прописываем свойство IsControl = true, а в шапке
класса меняем предка с TForm на TCustomControl; регистрируем класс в палитре
компонентов и вставляем по месту требования.
Впрочем, это лучше один раз увидеть на живом примере, чем многократно услышать.
WBR, Eugene mailto: www.tld.by@gmail*com
Alexander B. Bokovikov
<Eugene....@p24.f118.n450.z2.fidonet.org> wrote:
>Технология такова:
>создаем новую форму, в dfm прописываем свойство IsControl = true, а в шапке
>класса меняем предка с TForm на TCustomControl; регистрируем класс в палитре
>компонентов и вставляем по месту требования.
Разработкой компонентов особо не занимался с Delphi 2, так что не
знал, что такое возможно. А как регистрировать-то? Я знаю только один
способ регистрации компонентов - через пакеты. А здесь я вижу только
пункт "Add To Repository", но это не совсем то, что надо.
Eugene Kasnerik
... 18 июл 08 Alexander B. Bokovikov написал(а) Eugene Kasnerik:
>> Технология такова:
>> создаем новyю фоpмy, в dfm пpописываем свойство IsControl = true, а в
>> шапке класса меняем пpедка с TForm на TCustomControl; pегистpиpyем
>> класс в палитpе компонентов и вставляем по местy тpебования.
AB> Разpаботкой компонентов особо не занимался с Delphi 2, так что не
AB> знал, что такое возможно. А как pегистpиpовать-то?
Classes.RegisterComponents
AB> Я знаю только один
AB> способ pегистpации компонентов - чеpез пакеты.
Он и есть. Делаешь пакет с прообразом компонента (чисто чтобы в палитре
появилось существо) и регистрируешь. А потом наполняешь его контентом и при
каждом запуске оно подхватывает свое фактическое состояние (разумеется,
приложение нужно собирать с исходниками твоего компонента, а не с пакетом, в
котором от него пустышка).
А если нет нужды втыкать этот контрол в форму в design-time, то и
регистрировать ничего не нужно -- создал ручками и вставил куда надо.
WBR, Eugene mailto: www.tld.by@gmail*com
Вячеслав
ABB> При чем тут контролы? Хотите сказать, что форму можно так же
ABB> зарегистрировать, как и любой компонент?
Можно. И полезно.
http://www.howtodothings.com/computers/a1167-custom-containers-pack-ccpack-5.ht
ml
Вовсю пользуемся в своём проекте. Все формы - наследники одного предка, где
добавлены published - свойства, специфические для нашего проекта. Очень удобно
назначать в дизайн-тайм. И встраиванием пользуемся во всю. Сначала этот предок
был от TFrame, но потом переделали на TForm - меньше проблем.
А для фолдинга нарисовали компонент (невизуальный):
// - куда фолдить форму
property Place: TWinControl;
procedure update(ClassName: string; Param: Pointer);
если Place уже содержит форму нужного класса, вызваем у этой формы
refreshData(Param)
если формы нет или она другого класса - сначала создаём
TForm(GetClass(ClassName)).Create(Application);
потом
refreshData(Param)
потом фолдим новую и убиваем старую.
Alexander B. Bokovikov
wrote:
>http://www.howtodothings.com/computers/a1167-custom-containers-pack-ccpack-5.html
Все хорошо, только аднака линка дохлый совсем :)
http://www.geocities.com/sergey_orlik/ccpack5.zip
Вячеслав
ABB> Все хорошо, только аднака линка дохлый совсем :)
* Custom Containers Pack (CCPack 5) para Delphi 5
http://cc.codegear.com/Item.aspx?id=13985 (~695K)
* Custom Containers Pack source code port to Delphi 7
http://cc.codegear.com/Item/19483 (~356K)
* Custom Containers Pack source code port to Delphi 6 - 2006
http://cc.codegear.com/item.aspx?id=24236 (~584K)
Там, правда, для зарегистрированных.
Если с этим проблемы, могу заслать на мыло
ABB> ICQ 272074426
Alexander B. Bokovikov
wrote:
>* Custom Containers Pack source code port to Delphi 6 - 2006
> http://cc.codegear.com/item.aspx?id=24236 (~584K)
Заценил... Только все же не понял, в чем там суть. В смысле что именно
он облегчает? Вроде как только создание заготовки компонента. Даже
пакет надо самому рисовать через меню Install Component => New
Package. Что-то пропустил?
По ходу дела нашел причину глюка, описанного ранее (с потерей размера
фрейма). Если фрейму (или другому предку) поставить (при дизайне
композита) Align = alClient, то при переоткрытии файла с
компонентом-композитом его размеры теряются и становятся какими-то
дефолтными (маленькими). Если оставить alNone, то размеры сохраняются
такими, какими задал их при дизайне композита. Т.е. это не есть дефект
именно TFrame, это дефект IDE. Интересно, в более новых версиях так
же?
sl
ABB> Заценил... Только все же не понял, в чем там суть. В смысле что именно
ABB> он облегчает? Вроде как только создание заготовки компонента. Даже
ABB> пакет надо самому рисовать через меню Install Component => New
ABB> Package. Что-то пропустил?
Hу, тут, конечно, зависит от. В нашем проекте, как я уже говорил, создан и
зарегистрирован базовый класс (наследник TForm), в который добавили свои,
специфичные для проекта, published свойства. В-общем, в этом и есть основная
фишка этого пакета. Все прочие формы в проекте (кроме диалогов, about и т.п.)
- наследники этого класса (File\New\Other\InheitableItems у 2007-й или
File\New\Other\ЗакладкаПоИмениПроекта в 7-й). Сами по себе они не "плавают", а
встраиваются в другую форму - как фрейм, только в run time. Для этого
достаточно убрать у формы рамку и назначить Parent. Hу и Align, само собой.
Оказалось очень удобно, причём по многим параметрам. Так бывает - удачное
решение потом преподносит приятные сюрпризы, о которых ты даже не задумывался
при проектировании.
А вот фреймы мы практически повыкидывали. Даже если в run time ничего не
меняется, всё равно встраиваем форму своими силами. Просто IDE сильно глючит с
фреймами, особенно, когда у формы с фреймами есть наследники.
Andrew O. Shadoura
Artem Ivanov wrote:
> Смотря что писать. Если стандартные офисные приблуды - то конечно. Иначе -
> потоки нужны частенько.
Hа деле потоки нужны не так часто. Гораздо проще и эффективнее вместо
многопоточности использовать многопроцессовость, тем паче что она
кроссплатформенная (вопросы насчёт fork(2) оставим в стороне, т.к. не
касаясь того, что он есть не везде, замену ему найти всегда можно).
З.Ы. Кстати, тест. Букву "H" видно? Если где-то зарезало - сообщите,
пожалуйста.
--
Alexander Krasnitskiy
13 марта 2009 в 02:00, Andrew O. Shadoura ===> All:
AS> Artem Ivanov wrote:
>> Смотря что писать. Если стандартные офисные приблуды - то конечно.
>> Иначе - потоки нужны частенько.
AS> Hа деле потоки нужны не так часто. Гораздо проще и эффективнее вместо
AS> многопоточности использовать многопроцессовость, тем паче что она
AS> кроссплатформенная (вопросы насчёт fork(2) оставим в стороне, т.к. не
AS> касаясь того, что он есть не везде, замену ему найти всегда можно).
Hе согласен. Из моего опыта - потоки (threads) нужны просто постоянно.
Кстати, исходного письма у меня нет. Кто скушал?
AS> @PATH: 4500/1 450/1024 5020/545 4441 5030/966
AS> З.Ы. Кстати, тест. Букву "H" видно? Если где-то зарезало - сообщите,
AS> пожалуйста.
У меня "H" видна.
Удачи!,
Alexander
... "640K ought to be enough for anybody." - Bill Gates, 1981
Sergey Bychkov
... В ответ на письмо от 13 марта 2009 от Alexander Krasnitskiy к Andrew O.
Shadoura сообщаем:
>>> Смотря что писать. Если стандартные офисные приблуды - то конечно.
>>> Иначе - потоки нужны частенько.
AS>> Hа деле потоки нужны не так часто. Гораздо проще и эффективнее
AS>> вместо многопоточности использовать многопроцессовость, тем паче
AS>> что она кроссплатформенная (вопросы насчёт fork(2) оставим в
AS>> стороне, т.к. не касаясь того, что он есть не везде, замену ему
AS>> найти всегда можно).
AK> Hе согласен. Из моего опыта - потоки (threads) нужны просто постоянно.
AK> Кстати, исходного письма у меня нет. Кто скушал?
Судя по моим базам это письмо было в июне прошлого года :)
До встречи, Alexander!
Alexander Krasnitskiy
16 марта 2009 в 11:34, Sergey Bychkov ===> Alexander Krasnitskiy:
>>>> Смотря что писать. Если стандартные офисные приблуды - то
>>>> конечно. Иначе - потоки нужны частенько.
AS>>> Hа деле потоки нужны не так часто. Гораздо проще и эффективнее
AS>>> вместо многопоточности использовать многопроцессовость, тем паче
AS>>> что она кроссплатформенная (вопросы насчёт fork(2) оставим в
AS>>> стороне, т.к. не касаясь того, что он есть не везде, замену ему
AS>>> найти всегда можно).
AK>> Hе согласен. Из моего опыта - потоки (threads) нужны просто
AK>> постоянно. Кстати, исходного письма у меня нет. Кто скушал?
SB> Судя по моим базам это письмо было в июне прошлого года :)
У меня нет доступа к твоим базам :))
Как письмо пришло, так и ответил.
Sergey Bychkov
... В ответ на письмо от 16 марта 2009 от Alexander Krasnitskiy к Sergey
Bychkov сообщаем:
>>>>> Смотря что писать. Если стандартные офисные приблуды - то
>>>>> конечно. Иначе - потоки нужны частенько.
AS>>>> Hа деле потоки нужны не так часто. Гораздо проще и эффективнее
AS>>>> вместо многопоточности использовать многопроцессовость, тем паче
AS>>>> что она кроссплатформенная (вопросы насчёт fork(2) оставим в
AS>>>> стороне, т.к. не касаясь того, что он есть не везде, замену ему
AS>>>> найти всегда можно).
AK>>> Hе согласен. Из моего опыта - потоки (threads) нужны просто
AK>>> постоянно. Кстати, исходного письма у меня нет. Кто скушал?
SB>> Судя по моим базам это письмо было в июне прошлого года :)
AK> У меня нет доступа к твоим базам :))
AK> Как письмо пришло, так и ответил.
Как раз таки твой ответ вполне своевременен :) Я про исходное письмо, на
которое отвечал AS.