Size: a a a

2020 April 17

A

Alex in pro.cxx
просто непонятно, может, ещё чего-то не хватает? Судя по моим экспериментам, это не должно работать в std::map, но сейчас проверю
источник
2020 April 18

m

magras in pro.cxx
Dmitrij V
template<typename T>
class memory_allocator {
public:

 typedef T value_type;
 typedef std::size_t size_type;
 typedef std::ptrdiff_t difference_type;

 typedef T* pointer;
 typedef const T* const_pointer;
 typedef T& reference;
 typedef const T& const_reference;

 template<typename U>
 struct rebind { typedef memory_allocator<U> other; };

private:

 // для связного списка (придётся логику самому писать)
 struct block {
   pointer start, end, pos;
   block *prev, *next;
 };

 size_type block_size_;
 block *root_, *freed_, *pos_;

public:

explicit memory_allocator(size_type sz = 4096):
 block_size_(sz),root_(nullptr),freed_(nullptr),pos_(nullptr) {}

};
Сейчас уже не нужно указывать все типы вроде pointer, они определяются через трейты и имеют разумные дефолты.
источник

m

magras in pro.cxx
Alex
мне нужен аллокатор со внутренним состоянием, которое бы не терялось во время работы контейнера, и жило столько, сколько и сам контейнер
Statefull allcoator'ы стали доступны с 11 стандарта. Управлять "перемещениями" алокатора можно с помощью propagate_on_container_*.
источник

m

magras in pro.cxx
Еще если окей использовать виртуальные методы, появились (стандарт не помню, скорее всего 14 или 17) pmr аллокатор и контейнеры, с которыми намного удобнее работать.
источник

Н

НЛО in pro.cxx
https://t.me/joinchat/AAAAAFK2RwB-GIjBSY_nZQ

Фальшивые деньги
С рук не отличить
источник

M

Mxxx in pro.cxx
Max
Он зависает в состоянии TIME_WAIT чтобы гарантировать, что удаленная сторона получила подтверждение его запроса на отключение.
Отсюда вытекает ещё один способ борьбы с этим: пускай соединение разрывает подключающаяся сторона.
ну, да.
Вот и было интересно, можно ли этот состояние как-то форсированно отключать.
Отключать с подключающейся стороны не поможет. Там чёрная коробка стороннего сервиса.
источник

M

Max in pro.cxx
Mxxx
ну, да.
Вот и было интересно, можно ли этот состояние как-то форсированно отключать.
Отключать с подключающейся стороны не поможет. Там чёрная коробка стороннего сервиса.
1. SO_REUSEADDR. Потенциально может быть опасно, потому что кто-то может прослушивать трафик на этом же порту. Почитай как там конкретно в винде эта опция работает.
2. SO_LINGER.
3. TIME_WAIT состояние не возникает на стороне, которая отключается пассивно.
4. Почему вообще это проблема? Портов >65к.
5. Можно слушать всегда на одном, и редиректить клиентов на какой-то внутренний ipc.

Другие методы мне неизвестны.
Держи в уме, что TIME_WAIT состояние - это не прихоть, а вполне себе необходимость. Иначе может получиться так, что пакет из прошлой сессии внезапно поадёт в текущую.
источник

VO

Vyacheslav Olkhovchenkov in pro.cxx
нахрена вообще редиректить и заниматься вот этим вот всем?
источник

AK

Anton Kashcheev in pro.cxx
Ivan Azoyan
Короткий, вопрос. Когда приходишь в цикле по std::variant и вызываешь метод, вызывается он у конкретного типа. А как диспетчеризируется в конкретный тип? У std::variant а конструкторе тегом помечается конкретный тип?
Когда для себя делал вариант, решал это рекурсивно вложенными юнионами + номером поля. Диспечеризировал через проход по вложенным юнионам.
А так ранее верно заметили -- твоим ответом были бы исходники любой std.
источник

M

Max in pro.cxx
Mxxx
ну, да.
Вот и было интересно, можно ли этот состояние как-то форсированно отключать.
Отключать с подключающейся стороны не поможет. Там чёрная коробка стороннего сервиса.
Ну и 6 — всегда можно ограничить MLS таймаут общесистемно (TIME_WAIT == 2 * MLS).
Но это скользкая дорожка.
источник

M

Mxxx in pro.cxx
Max
1. SO_REUSEADDR. Потенциально может быть опасно, потому что кто-то может прослушивать трафик на этом же порту. Почитай как там конкретно в винде эта опция работает.
2. SO_LINGER.
3. TIME_WAIT состояние не возникает на стороне, которая отключается пассивно.
4. Почему вообще это проблема? Портов >65к.
5. Можно слушать всегда на одном, и редиректить клиентов на какой-то внутренний ipc.

Другие методы мне неизвестны.
Держи в уме, что TIME_WAIT состояние - это не прихоть, а вполне себе необходимость. Иначе может получиться так, что пакет из прошлой сессии внезапно поадёт в текущую.
1. SO_REUSEADDR отрубит другой сокет, который я мог прицепить к этому порту.
У меня есть пул портов, который я выдаю различным сессиям. И поэтому хотел бы, чтобы они работали на разных: просто перебираю порты, на которые получается прибиндится.
4. Не хотелось бы говорить людям: разрешите все порты, они могут пригодится
источник

M

Mxxx in pro.cxx
Max
Ну и 6 — всегда можно ограничить MLS таймаут общесистемно (TIME_WAIT == 2 * MLS).
Но это скользкая дорожка.
согласен
источник

M

Max in pro.cxx
Mxxx
1. SO_REUSEADDR отрубит другой сокет, который я мог прицепить к этому порту.
У меня есть пул портов, который я выдаю различным сессиям. И поэтому хотел бы, чтобы они работали на разных: просто перебираю порты, на которые получается прибиндится.
4. Не хотелось бы говорить людям: разрешите все порты, они могут пригодится
Да, SO_REUSEADDR - это специфично.
Порты — можно не все, а необходимое кол-во + запас. Сколько новых соединений ожидается за эти пару минут?
Может быть, вообще не разрывать эти соединения, если подключаются они же?
источник

CC

Chris Calvin in pro.cxx
Max
1. SO_REUSEADDR. Потенциально может быть опасно, потому что кто-то может прослушивать трафик на этом же порту. Почитай как там конкретно в винде эта опция работает.
2. SO_LINGER.
3. TIME_WAIT состояние не возникает на стороне, которая отключается пассивно.
4. Почему вообще это проблема? Портов >65к.
5. Можно слушать всегда на одном, и редиректить клиентов на какой-то внутренний ipc.

Другие методы мне неизвестны.
Держи в уме, что TIME_WAIT состояние - это не прихоть, а вполне себе необходимость. Иначе может получиться так, что пакет из прошлой сессии внезапно поадёт в текущую.
Почему вообще это проблема? Портов >65к. 

Есть нюансы когда требуется обеспечить свыше 60k RPS на физическую машину, но сомневаюсь что это этот случай.
источник

VO

Vyacheslav Olkhovchenkov in pro.cxx
не на физическую машину, а между двумя физическими машинами
источник

M

Max in pro.cxx
Chris Calvin
Почему вообще это проблема? Портов >65к. 

Есть нюансы когда требуется обеспечить свыше 60k RPS на физическую машину, но сомневаюсь что это этот случай.
и я о том. Такие задачи требуют других подходов.
источник

CC

Chris Calvin in pro.cxx
Vyacheslav Olkhovchenkov
не на физическую машину, а между двумя физическими машинами
Обеспечить обработку 60k RPS
источник

M

Max in pro.cxx
Vyacheslav Olkhovchenkov
не на физическую машину, а между двумя физическими машинами
нет, порт занимается целиком. Без разницы откуда клиент.
источник

VO

Vyacheslav Olkhovchenkov in pro.cxx
нет
источник

CC

Chris Calvin in pro.cxx
Оспариваете мою постановку моей задачи?)
источник