jcmvbkbc, Но он же явно хотел в monitor_thread переключать контексты.
А сейчас он в setcontext установил контекст из одного потока, и даже если будет использовать потом swapcontext в monitor_thread в другом потоке, то что будет когда переключится на этот контекст не понятно.
Но не суть. Все равно программа завершается слишком быстро и видимо ничего не успевает произойти.
Andrey_Epifantsev, В std::future есть wait_for/wait_until, где можно задать промежуток времени в течение которого ждать. Задайте там 0 (или что там минимально возможно), чтоб только проверить состояние задачи.
Но для вашей задачи, скорее всего, реально проще проверить, например, атомарный флаг завершения, чем разводить канитель с таймаутами во future.
На мой взгляд, std::async/future подходят для короткоживущих потоков, если у вас долгоиграющий, то это, видимо, не лучший вариант.
Вообще относитесь ко всем таким утверждениям как к рекомендациям, не более того. Всегда найдутся задачи, которые не укладываются в какие-то стандартные рамки. Впрочем, "голые" потоки такие же стандартные, но это универсальный механизм, на котором основаны все другие варианты.
fokin_nikolay1989, Читайте параметры из командной строки - смотрите функцию getopt (getopt_long). Примеров использования в интернете много.
Исключения - просто проверяете в теле цикла и пропускаете файл попадающий под условие.
Интересно. Но получается нужно делать статический МАС в arp компа с которого хотим будить, чтоб это работало. Тогда по идее любое TCP соединение способно разбудить ПК.
Proxy-arp наверняка кеширует МАСи, но рано или поздно кеш все равно протухнет.
Ну как бы еще и max_size должен быть double. Вы же пишите на Си, тут никто вам соломки не постелит.
Вам лучше max_size находить в целых в байтах, и только в самом конце его переводить в double перед самым выводом. Т.е. max_size пусть остается long long и в нем храните байты (а не Гб). Перед выводом вычисляете max_size в Гб и выводите: printf("%.2f GB\n", max_size / 1073741824.0);
Все числа целые, используется целочисленное деление, в этой операции остатка нет - число же целое.
Конвертируйте в double и выводите результат как double.
Можно так: max_size = file_stat.st_size / 1073741824.0;
fokin_nikolay1989, Как минимум можно вывести на экран путь после его формирования и убедится глазами, что такой файл есть в файловой системе.
Так же можно воспользоваться отладчиком.
Совет без кода:
Настраиваете систему на генерацию core dump. Компилируете программу с отладочными символами. Запускаете ее, она падает, получаете core dump файл.
Запускаете gdb открываете в нем core dump файл и там находите место, где произошел segfault.
Как анализировать core dump в gdb в интернете полно инструкций.
Если прикрутить у почтовика авторизацию в домене (АД например или другой LDAP), то достаточно завести пользователя в домен штатными средствами и ящик будет появляться сам.
Все современные почтовики это умеют, инструкции есть в интернете.
Вячеслав Шевченко, По идее опция explicit-exit-notify в клиентском конфиге должна помочь предотвращать подобные ошибки. У нее есть числовой параметр - количество попыток отправки уведомления. Попробуйте поиграться этим параметром - обычно рекомендуют указывать 2-3. Если не указано используется 1.
Но даже и без этого, клиент через какое-то время должен успешно повторно подключиться. Так что ошибку можно просто игнорировать. https://forums.openvpn.net/viewtopic.php?t=10674
Возможно тут стоит побороться не с самой ошибкой, а с причиной ее появления. Она может появляться когда клиент отваливается при его повторном подключении. Из-за чего клиент отваливается? Плохое качество связи или еще что?
1. На сервере указан udp6, на клиенте udp. Определитесь.
2. На клиенте в опции remote указан адрес и порт сервера? Если нет, то куда подключается клиент?
Сергей Якушев, Это не ваш сертификат, а сертификат сбера, на сервере сбера.
Вы в команде никаких своих сертификатов не указываете, да это обычно и не нужно для HTTPS подключения, хотя возможно.
Я бы так не сказал. Это самоподписанный сертификат. Такой сертификат может выпустить кто угодно. Доверять такому сертификату нельзя.
В первом случае, судя по всему, вообще на той стороне нет SSL. Если бы использовался, например, какой-то другой алгоритм шифрования, то ошибка была бы другая. Кстати, это же подтверждает и @paran0id
Для такой конторы как сбер, использовать самоподписанные сертификаты - "это какой-то позор" :)
Можно поместить этот "self signed certificate" в доверенные сертификаты, возможно это можно сделать опциями curla или еще как-то.
Или вы можете использовать совет: "If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option.". Тогда curl не будет проверять сертификаты. Но это, конечно, плохой вариант, годится только как какое-то временное решение.
Одновременно написать в поддержку сбера об имеющейся проблеме, пусть решают.
В гите есть теги. Вы можете использовать гитовые теги для привязки версии софта к комиту. Тогда можно легко переключаться по версиям используя тег вместо имени ветки или комита. git tag --help
Теги надо отдельно синхронизировать с удаленным репозиторием. Но, обычно, это достаточно сделать один раз, когда создается тег.
gohellp, Судя по всему SDK у вас уже стоит. Видимо, вам надо в вашем проекте выбрать ту версию SDK, которая у вас установлена, а не устанавливать SDK под проект.
Конкретно настройку не скажу, давно студию в руки не брал, но оно там точно есть.