Редактировалось 5 раз(а), последний 2021-05-21 05:32:18

Редактировалось 5 раз(а), последний 2021-05-21 05:32:19

Редактировалось 5 раз(а), последний 2021-05-21 05:32:19

схему в студию

Гусары - МАЛЧАТЬ

MailSlot_Server использует стандартный класс потока и его метод Synchronize. Этот метод не работает в консольном приложении.
Можно в THIMailSlot_Server._OnExec перед Sender.Synchronize(SyncExec) проверять наличие Applet, если нет - делать просто вызов SyncExec.

А кто за последствия отвечать будет: тот - кто внес предложение, или тот - кто внес правку на svn

Последствия будут только если в программе будет намешано много других потоков, которые будут работать с одними и теми же данными. В такой ситуации пользователю нужно будет разбираться с конкурирующими потоками независимо от наличия компонента MailSlot_Server. На форуме помогут.
Во всяком случае "не работает" против "работает, но с осторожностью"

"Если" - уже есть безусловно. Если мы заводим поток (а мы заводим), то значит у нас есть уже хотя бы один, из которого и заводим.

Лучше скажите мне, какая такая есть Великая Причина, заставляющая делать именно консольное приложение, а не оконное (например - невидимое).
По мне, таковая может быть только одна - не хочу заморачиваться с обработкой очереди сообщений.

Ну тогда и не надо искать у отвертки usb-порт.
И не надо приделывать его к отвертке.
Как мне кажется

В случае консольного мультипоточного приложения этот поток после запуска полезной работы в параллельных потоках ставится на паузу, чтобы не дать закрыться программе, пока не отработают полезные потоки. А вот регулирование взаимодействия полезных потоков - задача программиста (как и в визуальных приложениях). Метод Synchronize - один из вариантов, и то не самый оптимальный.

Про причины создания консольных приложений - без понятия.

------------ Дoбавленo в 13.15:

Пример консольного MailSlot - сервера: mailslot console server.sha
Пример клиента: mailslot client.sha
Попробуйте поотправлять данные серверу: вы ничего не увидите, так как сервер не работает в консольном приложении.
Внесите следующую поправку в файле hiMailSlot_Server.pas (в процедуре THIMailSlot_Server._OnExec):
Сервер заработает.
В консольном примере работает 3 потока. Проблем не заметил (что не отменяет вышеизложенных соображений по работе с потоками в более сложных схемах)

[offtop]PS: отдельно зацените "удобство" метода doCreate в компоненте Events[/offtop]

Хех
Вы подтвердили еще раз мое наблюдение:

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

Мне не нужны доказательства, что с потоками могут быть проблемы - я имею достаточное представление о их работе, чтобы заставлять их работать там, где мне нужно (и где это в принципе возможно). Соответственно, и многие грабли мне известны.

Опять же, мне не нужны: я считаю что сделал лучше, потому что заставил работать то, что не работало в заданных условиях.

А означает, что есть некоторые задачи, для которых предоставлено рабочее решение. И то, что при работе с потоками следует соблюдать некоторые правила, не значит, что нужно любыми способами избегать применения потоков (мол, пусть приложение превращается в "кирпич" - зато надежно и не надо ещё и потоки изучать).

Редактировалось 1 раз(а), последний 2019-06-03 10:45:36

Нет, не заставил.
Ты сказал, что проблем не заметил.
А это не означает, что он работает.
Мне нужны доказательства, что оно работает. Потому-что я Инженер. "Проблем не заметил", доказательством к этому не является.
А тебе не нужны.


Но предложил решение тому, кто об этом не знает. И внести это в элемент.
Я ничего не перепутал

---

Netspirit, нет у меня желания спорить. Это разные концепции.
ПРОСТО, я положил себе копилку еще одно наблюдение. И сообщил об этом.
Хочешь "планировать себе проблемы" - планируй. Ну не могу я тебе этого запретить, конечно же.

С наблюдением - не спорю, правильное наблюдение.
Доказательством есть предложенная схема - она работает. Работает - и точка. Теперь могу выслушать контраргумент (как говоришь, "доказательство, что не работает").
Всё верно.
Вопрос в том, считаем ли мы это плохим или нет. Я - не считаю. "Не работает в консоли" хуже, чем "работает, но в параллельном потоке". Что плохого в принципе "работает, но в параллельном потоке"? То, что пользователь обратится на форум с ошибкой в схеме, ему объяснят про потоки, предложат решение? Не будем здесь акцентировать на нежелании пользователей учиться и т.п.

Не поленюсь повториться: Никакое тестирование не доказывает работоспособность программы. Оно лишь может доказать ее неработоспособность
Добавлю лишь, что это не мое мнение.
И даже не предмет обсуждения.


Ключевое слово - "работает".
Если говорить об изменении в элементе, то работоспособность некой одной схемы - вообще надо засунуть куда подальше.
И в топике говорилось не о неработоспособности конкретной схемы, а о неработоспособности MailSlot в консольном приложении.
А по результатам теста можно лишь заключить о: "возможно заработает".
И не более.
А сослагательное наклонение, по определению - ХУЖЕ.
Было бы лучше, сразу бы выкинули событие на улицу, безо всякого Synchronize.
Типа - "у юзера голова большая, пусть думает. Если чего - пусть на форум обращается, там помогут".

Не подумайте, что я вообще против асинхронной работы.
Есть необходимость - надо работать. С другим уровнем знаний, правда.
Но мне нужно предъявить эту необходимость.
И первое, что я и спросил - нафига консоль. А Вас, Netspirit, этот вопрос вообще не взволновал.
Разницу в концепциях ощущаете


Как же, плавали - знаем.
Приходит юзер, и спрашивает "у меня схема из 2000 элементов, раз в два дня падает. Раньше реже падала... Чего делать?"
Можно еще добавить, что пока была размером с Ваш тест - вообще не падала.
Типа " Работает - и точка."

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