Очень давно хотел разобраться. В данной области, в университете, не сложилось системного представления. Только кусочно. Решил избавляться потихоньку от белых пятен. Читаю Таненбаума, но воспринимается тяжеловато. Думаю, неоднократно буду перечитывать.
Это не совсем то. Я посмотрел, статьи действительно интересные, но они решают некоторую локальную узкую задачу. Так же, не нашёл ничего на тему подходов проектирования таких устройств как Raspberry pi или что нибудь с контроллером и ОС.
Если это так, то Вы счастливый человек, который обладает большим количеством свободного времени=) К сожалению, у меня не все так хорошо со свободным временем, и приходится пользоваться уже написанными продуктами.
Алексей С.: Согласен. Но тогда причём тут белый адрес? На сколько я знаю, белый адрес это выделенный ip, получаемый у провайдера. Или я не правильно понимаю что-то?
Да, тут все ясно написано. Но я боялся, что где то есть еще какая нибудь информация, или нюанс на тему того, что в таком то случае нужно покупать. Я сам далек от лицензионных соглашений, к сожалению. Спасибо!
| У вас просто в архитектуре гипотетического приложения - ошибка, а в голове - путаница (относительно потоков).
Спасибо, толковое объянение)
Вы можете посоветовать что почитать на тему потоков, чтобы хорошо разобраться? Я сейчас читаю книгу "параллельное программирование на с++" Уильямса. Может быть я не с того начал или еще чего.
В общим, проблема с разделенным ресурсом между потоками. Это boost::io_service. я читал про корректную обработку закрытия сокета и там говорилось примерно следующее, что нужно остановить цикл обработки очереди событий (event loop) в io_service, а потом выполнить socket_obj.close(err);
если одному потоку удается аккуратно закрыть соединение, то второй крашится от того, что io_service уже закрыл event_loop. может быть там фигня какая. Я в boost не силен(
да, примерно так) я не понимаю, как можно сделать join_all. Как это в реализации работает? ведь как только делаешь join(), то основной поток выполнения ждет, пока присоединенный завершит работу.
Единственное, что приходит на ум, это сделать обёртку над std::thread и в деструкторе этой обертки сделать thread_guard