MM
спасибо
Size: a a a
2020 June 20
MM
хотя это что-то вообще же не про то
AM
хотя это что-то вообще же не про то
ASLR адреса не раскидает разве?
MM
ASLR адреса не раскидает разве?
так дело не в том, как они раскиданы. а в том, одинаковые они или нет. т.е. по факту будет один объект или разные.
АК
ASLR адреса не раскидает разве?
а причем тут модули-то?
если переменная одна, то и адрес один должен быть
если переменная одна, то и адрес один должен быть
MM
должен-то быть один
MM
а тут хлоп - и разные
MM
а причем тут модули-то?
если переменная одна, то и адрес один должен быть
если переменная одна, то и адрес один должен быть
именно (если речь о переменной в module interface unit)
AM
именно (если речь о переменной в module interface unit)
Оу, тут я просмотрел
ПК
Вопрос по boost::beast (и asio).
Возьмём пример асинхронного http сервера из документации. Является ли вызов async_write потокобезопасным? Например, в on_read я не сразу вызываю async_write, а создаю отдельный поток, который ждёт 3 секунды и после вызывает async_write. Нужно ли что-то блокировать для этого? Или проверять валидность каких-нибудь объектов?
Судя по доке - всё должно быть ок, так как никаких других асинхронных операций на данной сессии у меня после on_read быть не может (повторное чтение я не запускал, запись также ещё не началась), а значит и async_write можно звать без синхронизации.
Все объекты в shared_ptr + enable_shared_from_this, так что ссылки не протухнут
Возьмём пример асинхронного http сервера из документации. Является ли вызов async_write потокобезопасным? Например, в on_read я не сразу вызываю async_write, а создаю отдельный поток, который ждёт 3 секунды и после вызывает async_write. Нужно ли что-то блокировать для этого? Или проверять валидность каких-нибудь объектов?
Судя по доке - всё должно быть ок, так как никаких других асинхронных операций на данной сессии у меня после on_read быть не может (повторное чтение я не запускал, запись также ещё не началась), а значит и async_write можно звать без синхронизации.
Все объекты в shared_ptr + enable_shared_from_this, так что ссылки не протухнут
все io объекты в asio (streams, sockets и т.д.) не являются потокобезопасными при использовании одного объекта из разных потоков (как нельзя юзать push_back у вектора из разных потоков, так нельзя и async_* и close например вызывать из разных потоков)
ПК
Так что если юзаешь объект из разных потоков надо лочить мьютекс или другие синхронизации делать (типа strand).
ПК
Вообще норм тема делать всё в одни поток, тогда не надо вообще париться с синхронизациями
ПК
Получается io_context будет крутиться в 1 потоке, а не в пуле
АК
Так что если юзаешь объект из разных потоков надо лочить мьютекс или другие синхронизации делать (типа strand).
я не большой специалист по asio, но в том примере http server'а как раз прописаны strand в нескольких местах с комментарием "для потокобезопасности", но я не уверен, что в случае выделения async_write в отдельный поток мне не нужен ещё один strand
касательно одного сетевого потока - он и будет одним, просто я рассматриваю ситуацию, когда приходит запрос из сети, я отправляю его в другой логический поток (что-нибудь вычислить/сходить в БД/...), и этот поток при завершении операции зовёт коллбэк, который и выполняет async_write
касательно одного сетевого потока - он и будет одним, просто я рассматриваю ситуацию, когда приходит запрос из сети, я отправляю его в другой логический поток (что-нибудь вычислить/сходить в БД/...), и этот поток при завершении операции зовёт коллбэк, который и выполняет async_write
ПК
я не большой специалист по asio, но в том примере http server'а как раз прописаны strand в нескольких местах с комментарием "для потокобезопасности", но я не уверен, что в случае выделения async_write в отдельный поток мне не нужен ещё один strand
касательно одного сетевого потока - он и будет одним, просто я рассматриваю ситуацию, когда приходит запрос из сети, я отправляю его в другой логический поток (что-нибудь вычислить/сходить в БД/...), и этот поток при завершении операции зовёт коллбэк, который и выполняет async_write
касательно одного сетевого потока - он и будет одним, просто я рассматриваю ситуацию, когда приходит запрос из сети, я отправляю его в другой логический поток (что-нибудь вычислить/сходить в БД/...), и этот поток при завершении операции зовёт коллбэк, который и выполняет async_write
если у тебя в момент вызова async_write никто больше by design не может вызвать методы у сокета, то всё норм, насколько я понимаю. Один поток как бы и остаётся
ПК
Но ты в любом случае можешь вместо непосредственного вызова async_write сделать post в strand, который будет крутиться в единственном потоке отвечающим за asio.
ПК
Но ты в любом случае можешь вместо непосредственного вызова async_write сделать post в strand, который будет крутиться в единственном потоке отвечающим за asio.
А, не. В таком случае strand не нужен, раз поток под asio один. Это я погнал. Это называется "естественный strand" или типа того
АК
если у тебя в момент вызова async_write никто больше by design не может вызвать методы у сокета, то всё норм, насколько я понимаю. Один поток как бы и остаётся
ну вообще, методы звать никто не должен, так как там схема простейшая:
async_accept -> on_accept -> async_read -> on_read -> [из другого потока через 5 секунд] async_write -> on_write -> (async_read или close)...
в этой схеме я не вижу проблем, но меня напрягает, например, что на сокете зовётся в самом начале:
не может ли это привести к тому, что
async_accept -> on_accept -> async_read -> on_read -> [из другого потока через 5 секунд] async_write -> on_write -> (async_read или close)...
в этой схеме я не вижу проблем, но меня напрягает, например, что на сокете зовётся в самом начале:
stream_.expires_after(std::chrono::seconds(30));не может ли это привести к тому, что
io_context в какой-то момент сам вызовет операцию на сокете? или если я на сокете не вызываю методы, то они сами в связи с какими-либо событиями и не вызовутся?ПК
ну вообще, методы звать никто не должен, так как там схема простейшая:
async_accept -> on_accept -> async_read -> on_read -> [из другого потока через 5 секунд] async_write -> on_write -> (async_read или close)...
в этой схеме я не вижу проблем, но меня напрягает, например, что на сокете зовётся в самом начале:
не может ли это привести к тому, что
async_accept -> on_accept -> async_read -> on_read -> [из другого потока через 5 секунд] async_write -> on_write -> (async_read или close)...
в этой схеме я не вижу проблем, но меня напрягает, например, что на сокете зовётся в самом начале:
stream_.expires_after(std::chrono::seconds(30));не может ли это привести к тому, что
io_context в какой-то момент сам вызовет операцию на сокете? или если я на сокете не вызываю методы, то они сами в связи с какими-либо событиями и не вызовутся?expires_after насколько я понял просто отменяет последующую http::async_read через 30 секунд если она не успеет выполниться. И всё так же вызовется on_read, но с ошибкой. Тут правда не до конца ясно, если async_read выполнится успешно за 30 секунд, это получается отменит таймаут? Думаю, да, но 100% подтверждения не нашёл.
Всё таки советую async_write вызывать в net потоке через post. Это выглядит более стройно
Всё таки советую async_write вызывать в net потоке через post. Это выглядит более стройно
АК
expires_after насколько я понял просто отменяет последующую http::async_read через 30 секунд если она не успеет выполниться. И всё так же вызовется on_read, но с ошибкой. Тут правда не до конца ясно, если async_read выполнится успешно за 30 секунд, это получается отменит таймаут? Думаю, да, но 100% подтверждения не нашёл.
Всё таки советую async_write вызывать в net потоке через post. Это выглядит более стройно
Всё таки советую async_write вызывать в net потоке через post. Это выглядит более стройно
спасибо, перестрахуюсь и сделаю через post