DS
dismiss_button называется guard :)
Ну если там F это generic функция, без всяких unique, то без shared не обойтись. Shared это провод от dismiss_button до dismissable_fn.
Size: a a a
2020 June 17
CD
Ну если там F это generic функция, без всяких unique, то без shared не обойтись. Shared это провод от dismiss_button до dismissable_fn.
Там в любом случае без shared не обойтись, операция на самом деле make_shared_dismissable
CD
Интересно, есть вообще штатное название для метода
void left_blackhole(T& t) { t_ = std::move(t); }
который переводит объект в moved out state?CD
не использовать же имена unique_blackhole и shared_blackhole :)
DS
Там в любом случае без shared не обойтись, операция на самом деле make_shared_dismissable
Но если всё таки в очереди есть какой то basic task который сам по себе shared, чего бы ему не приделать прям в виде базовой функциональности dismiss?
CD
Но если всё таки в очереди есть какой то basic task который сам по себе shared, чего бы ему не приделать прям в виде базовой функциональности dismiss?
Я пока застрял на уровне восстановления концепта из TypeErasure
CD
А именно на том, как называется метод dismiss на самом деле
CD
То есть тут на самом деле два метода
1) operator () &&
2) shared_blackhole? операция, которая переводит объект по левой ссылке в moved out state
1) operator () &&
2) shared_blackhole? операция, которая переводит объект по левой ссылке в moved out state
CD
Ты меня понимаешь? :))
CD
В многопоточном случае это был бы какой-то эквивалент сущностей типа shared_mutex с раздельным личным и общим доступом
DS
В многопоточном случае это был бы какой-то эквивалент сущностей типа shared_mutex с раздельным личным и общим доступом
Ну в многопоточном варианте можно какой нить shared atomic flag выставить типа dismised и проверять перед invoke либо реально лочиться (например на уровне самого сообщения, через spinlock на shared bool) и убивать payload если прям так важно сделать dismiss с освобождением ресурсов.
CD
Ну в многопоточном варианте можно какой нить shared atomic flag выставить типа dismised и проверять перед invoke либо реально лочиться (например на уровне самого сообщения, через spinlock на shared bool) и убивать payload если прям так важно сделать dismiss с освобождением ресурсов.
Мне все еще очень сильно кажется, что dismiss это намного более универсальная операция
CD
void shared_blackhole(T& t) { auto t_ = std::move(t); }которая записывается вот примерно так
CD
собственно для std::function
void dismiss() noexcept override { utils::blackhole(std::move(wrapped_)); };
просто является разумной реализацией (с точностью до bad_function_call, но это точно плохо?)CD
template<typename T> void blackhole(T&& t) { /*static_assert T is not reference*/ auto unused = std::move(t); }
черная дыра для уникального владельца прилагаетсяCD
Ну в многопоточном варианте можно какой нить shared atomic flag выставить типа dismised и проверять перед invoke либо реально лочиться (например на уровне самого сообщения, через spinlock на shared bool) и убивать payload если прям так важно сделать dismiss с освобождением ресурсов.
В многопоточной среде там должен собственно встать recursive_shared_mutex, потому что operator() && должен заблокировать возможность dismiss
CD
Это единственный способ гарантировать, что dismiss отпускает все ссылки
CD
(возможно, не recursive, вызов dismiss в operator() не дает такой гарантии)
DS
Хз, вроде как для той же function = nullptr это и есть reset, вызов ~F, зачем move?
CD
Хз, вроде как для той же function = nullptr это и есть reset, вызов ~F, зачем move?
Не нужен, конечно. Это пример, что эта реализация работает