Работа с потоками в Delphi

← →
Piter © (2009-01-26 22:50) [40]

Удалено модератором

← →
Piter © (2009-01-26 22:51) [41]

Удалено модератором

← →
Palladin © (2009-01-26 23:04) [42]

Удалено модератором

← →
ketmar © (2009-01-27 00:53) [43]

>[31] Дмитрий С (2009-01-25 17:54:00)
>Как обычно одни указания и ничего конструктивного. Даже объяснять ничего не
>хочу.
*мне* кагбэ и не надо. а ты — фигню сказал.

>[30] Игорь Шевченко © (2009-01-25 17:00:00)
>Если ты не видишь дальше собственного носа, я тебя уговаривать не собираюсь, это
>всего лишь говорит о твоей ограниченности.
а может то, что я вынужден писать руками базовый код, который в нормальной системе наличествует изначально — это не я не вижу чего-то, а система уродлива? а ну как у меня всё жёстко завалилось, так, что уже и апи не позвать? чего тогда? писать свой ядерный драйвер для дампов? круто, ничего не скажешь.

---
Understanding is not required. Only obedience.

← →
Игорь Шевченко © (2009-01-27 13:32) [44]

ketmar © (27.01.09 00:53) [43]

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

Это что - единственное отличие ? Больше никаких не существует и только необходимость писать N строчек кода для получения post-mortem dump является тормозом для создания кросс-платформенного приложения ?

← →
ketmar © (2009-01-27 16:22) [45]

>[44] Игорь Шевченко © (2009-01-27 13:32:00)
>Это что — единственное отличие ?
нет. но очень неприятное.

>олько необходимость писать N строчек кода для получения post-mortem dump
>является тормозом для создания кросс-платформенного приложения ?
ещё, как минимум, отсутствие в винде позикса (и fork()"а в частности). благодаря чему я не могу написать кроссплатформенный backend и прилепить к нему «родные» гуя где надо.

да даже несчастного аналога valgrind — и того нет! а если бы не портировали gcc — то и компилятора нормального не было бы.

---
Understanding is not required. Only obedience.

← →
Piter © (2009-01-27 21:32) [46]

Удалено модератором

← →
Игорь Шевченко © (2009-01-27 22:17) [47]

ketmar © (27.01.09 16:22) [45]

> ещё, как минимум, отсутствие в винде позикса (и fork()"а
> в частности).

Если бы у бабушки были колеса, то это была бы не бабушка, а трамвай.

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

Я к чему - может, не стоит считать, что одно безусловно хорошее, а другое безусловно плохое, когда оно просто разное ?

> а если бы не портировали gcc — то и компилятора нормального
> не было бы.

Извини, но к gcc я за много лет так и не смог привыкнуть, потому о нормальности ничего сказать не могу. Мне от компилятора немного надо - чтобы он исходный код в объектный превратил, а большего не требуется. А с gcc почему именно в этом процессе у меня возникали проблемы.

← →
MsGuns © (2009-01-27 22:51) [48]

>ketmar ©

Если ты считаешь что посмертный дамп - всеобщая панацея, то ты мнишь о себе слишком много. Более того, в подавляющем большинстве сред программирования он как зайцу пианино. Поэтому нефиг делать лицо как у лемура когда кто-то не слышал о дампе.
Хотя, конечно, каждый кто не знаком с асмом - лох, ламер и неудачник :)

← →
ketmar © (2009-01-28 01:57) [49]

>[47] Игорь Шевченко © (2009-01-27 22:17:00)
>Кстати, что интересно — за свой долгий опыт ни разу не видел реальных
>кроссплатформенных приложений, за исключением написанных на разного рода
>интерпретируемых языках.
потому что платформы, в принципе, аж две, и одна их них не держит posix. %-)

ну, и гуя — это отдельная песня, да.

>Мне от компилятора немного надо — чтобы он исходный код в объектный превратил, а
>большего не требуется.
угу. вот у m$vc с этим как раз огромные проблемы, потому что C99 мы не понимаем. а gcc — понимает, за что получает жирный респект.

>с gcc почему именно в этом процессе у меня возникали проблемы.
ну, mingw в своё время был страшен, конечно. щаз чуть получше стал.

>[48] MsGuns © (2009-01-27 22:51:00)
чего ты дёрганый такой, а? ну жил ты без этой фичи — и живи дальше, «запорожец» — тоже машина.

---
All Your Base Are Belong to Us

← →
SPeller © (2009-01-28 02:14) [50]

Не пойму одного - Торвальдз за рекламу приплачивает?

← →
ketmar © (2009-01-28 06:11) [51]

>[50] SPeller © (2009-01-28 02:14:00)
а ты думаешь, откуда у линуксоидов интернеты?

---
Do what thou wilt shall be the whole of the Law.

← →
SPeller © (2009-01-28 07:24) [52]

Тогда оно должно умереть как и весь сетевой маркетинг )

← →
MsGuns © (2009-01-28 09:48) [53]

>ketmar © (28.01.09 01:57) [49]
>чего ты дёрганый такой, а? ну жил ты без этой фичи — и живи дальше, «запорожец» — тоже машина.

Я - дерганный ? :))
Я, уважаемый, было время, из этих самых "посмертных" не вылазил, ибо на ЕС ЭВМ (позже на СМ-4М) других удовлетворительных средств поиска ошибок не было.
В дельфи нынче они мне просто не нужны ибо вполне обхожусь дебаггером. Хотя, для справедливости, операционных систем не пишу :) Тут таки да, тебе не пара :)

> MsGuns (28.01.2009 9:48:53) [53]

DurdomOS

>[53] MsGuns © (2009-01-28 09:48:00)
я тоже ОС не пишу. и сидел в дельфийском отладчике, пока не перешёл сначала на writeln, потом на ОС, где есть дампы. потому что отладчик дичайше неудобен.

---
All Your Base Are Belong to Us

← →
имя (2009-02-19 14:21) [56]

Удалено модератором

← →
ANB (2009-02-20 13:35) [57]

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

топикстартеру: отлаживать многопоточное приложение пошаговым отладчиком - дело совершенно бестолковое. Т.к. весь кайф потоков в одновременном их исполнении, в этом же и все "глюки".
Т.е. просто надо заставить себя переходить ан следующий уровень: сначала тщательно планировать как мы разносим приложение на потоки, как будем организовывать взаимодействие между потоками, отдельно продумывая коллизии по чтению/изменению общих данных потоков, если таковое имеется.
Только после этого есть смысл начинать писать код. Причем отлаживать его пошагово - уже совершенно бесполезно; максимум что тут поможет - логи, да и то беда в том, что логирование может маскировать ошибку, т.к. выполнение команд потоков сдвинется во времени, т.е. ошибка может "исчезнуть", а вернее - просто замаскироваться. Особенно, понятно, это наглядно будет видно при применении защищенного многопоточного логирования в один файл, когда потоки из-за логирования будут подсинхронизироваться.

оказывается в эту ветку я это уже писал, сорри :)

Работа с потоками в Delphi Найти похожие ветки