Всем привет.

Ситуация вроде самая стандартная. Есть TIdUDPClient, есть читающий поток, который в цикле вызывает ReceiveBuffer(). Таймаут ожидания бесконечный (это важно), то есть пока нет данных, читающий поток в перманентном ожидании.

Вопрос на засыпку: как из основного потока сделать так, чтобы прервать работу ReceiveBuffer() и дать читающему потоку корректно завершиться?

Просто закрыть сокет -- не вариант по двум веским причинам (если кому интересно, объясню).

Может, потому что нужен именно клиент?


Нихрена он не очевиден. И даже вреден. Не думал что тут придется объяснять, почему.


Легально послать такой пакет может только сервер, а он ни сном ни духом, что клиент хочет отключиться.

Я подозреваю, что эти две причины не имеют ничего общего с главной и единственной:
закрытие сокета не обязано прерывать ожидание. Хотя на Windows и делает это.
Это одна из причин. А другая в том, что код Indy так написан, что даже если прервать ожидание закрытием, сокет тут же пересоздается.

Да, таки работает. Просто не думал, что сокет может так просто самому себе отослать байт. Есть некоторые сложности с биндингом на конкретный адаптер, но это решаемо. Спасибо!

Именно это и мешает. С таким подходом я не могу прибить поток (вместе со всем, что на него завязано) тогда, когда мне это нужно. Вместо этого приходится ждать до истечения таймаута, пока поток просрется очнется и будет готов завершиться.

А уменьшение таймаута увеличивает паразитную нагрузку на процессор, и в моем случае его пришлось бы уменьшить до 10 мс, что вообще ни в какие ворота.

И да, не нужно забывать про принцип " никогда ничего не опрашивай " (есть перевод от Гансмокера).

Я не могу ждать завершения потока более 10 мс, будет заметный затык анимации. Можно было бы вынести создание и завершение этих потоков в еще один поток, но слишком геморройно. Передача байта для просыпания тоже не самое красивое решение, если представить путь этого байта от процесса и назад к нему же, но это все равно гораздо лучше опроса 100 (да и даже 10) раз в секунду. Тем более что код будет работать в том числе и на мобилке.

_Vasilisk_, щас, блин. Не хватало мне еще самому это под все платформы писать.

Dimitry Sibiryakov, никто не говорил про завершение работы. Речь идет про отключение UDP-канала, которое случается периодически в процессе работы программы.

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

Dimitry Sibiryakov, кроссплатформа, блин! Вы тему читали? Если я начну даже сокеты сам реализовывать, поект на год затянется.

Пофиг. BSD сокеты одинаковы на всех платформах.
Угу, вот только BSD сокеты как раз насквозь синхронные, а пулинг везде разный.

Windows Messages ничем не отличатся от
X-Windows Events.
А под ведром что прикажете посылась? Или в огрызке? Я уже молчу, что завязывать подобные вещи на X в линуксах -- совсем уж дурной тон даже для GUI-приложения.

Dimitry Sibiryakov, select() как бы синхронный. А если навешивать на него еще и семафор для отпускания потока, то это уже за рамками POSIX, и мы возвращаемся иуда же: куча кодинга, отладки, глюков на ровном месте.