Не совсем подходящее место, возможно. Но подскажите, кто может - в линуксе, нажав Ctrl-C, я посылаю сигнал процессу и все системные вызовы прерываются со значением -1 и ошибкой errno == EINTR. В винде же, когда я устанавливаю обработчик Ctrl-C с помощью SetConsoleCtrlHandler, обработчик-то вызывается, как положено, но вот системные вызовы не прерываются. И если приложение ждет данных по сети, то оно зависает даже несмотря на Ctrl-C. И только прочитав данные из сети приложение выходит. Как можно обойти это ограничение? Понятно, что я могу переписать приложение, чтобы оно мониторило данные на дескрипторе и читало только когда данные пришли, но хотелось бы более портабельный код.

Боюсь, портабельным образом - никак. Хотя, может быть, boost поможет...
Впрочем, сигналы для Windows - это тоже чужеродное явление, никак не портабельное.


Это сообщение отредактировал(а) feodorv - 16.12.2012, 15:21

А как можно прервать в Windows системный вызов? Чтобы попробовать сымитировать такое поведение.

Обычно создают специальное событие, которое добавляют в список объектов для Wait-функций, и для которого делают SetEvent в обработчике ^C. Для этого всё работу по сети придётся переводить на неблокирующие или асинхронные сокеты...
Можно пробовать просто закрыть сокет, системный вызов должен вывалиться с соответствующей ошибкой, но это очень грубо.

Необязательно. Вот есть статья ...

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

вопрос к drug007, а как Вы штатно завершаете приложение ?

Добавлено через 11 минут и 14 секунд
xvr, интересная статья, но... решение для асинхронных операций выглядит ужасно
 
для синхронных же - вполне норм.

Грубо по отношению к потоку, который использует этот сокет. Этот поток должен быть готов к внезапной кончине сокета, виси он на синхронной функции или занимайся другими делами. Если этим пользоваться только при закрытии программы, то, может, и нормальный способ. В общем случае можно получить неприятности (скажем, другой поток в этот момент открывает сокет, хендлер которого по случайности оказывается равным ранее закрытому хендлеру сокета). Да и с shutdown как быть непонятно...

Извиняюсь, что долго не заходил

Дело в том, что я сейчас знакомлюсь с библиотекой zeromq и портирую некоторые примеры из руководства на язык D. Как в библиотеке реализовано завершение работы, честно говоря, не смотрел. Под никсами при вызове библиотечной функции zmq::ctx _t::terminate() все синхронные вызовы возвращают -1 и устанавливают ошибку EINTR. Под виндой же синхронные вызовы ждут, чтобы хоть что пришло и только после этого возвращают управление. В принципе, более сложные примеры, использующие поллинг дескриптора перед работой с ним, правильно работают и под виндой. А вот простые примеры в винде не работают - без поллинга чтение из сокета подвешивает приложение пока что-то не придет на этот сокет и только потом приложение завершается, что новичка (а туториал же для них) будет сбивать с толку.  Делать поллинг в простых примерах тоже не комильфо - я же не автор руководства, а лишь портирую его на другой язык. Вот и хотел посоветоваться, как можно простым способом решить этот вопрос. Пока в качестве workaround'а вижу только прямой текст, что так и так, под windows вы получите такой и такой эффект по такой-то и такой-то причине...

xvr, спасибо за статью, но слишком сложное решение в данном случае.

Добавлено @ 08:39

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

Это сообщение отредактировал(а) drug007 - 20.12.2012, 08:43