История изменений

А как синхронизовать время жизни объекта и этого глобального контроллера? Нужно копировать все указатели на выделенные ресурсы?

Давай для начала конкретизируем понятие ресурсов, потому как подходы к памяти, идентификаторам, сокетам могут быть разными.

Мы говорим о соединениях, если я правильно понял.

1. Во-первых, я так и не понял, что входит в понятие «закрыть соединение», и почему это происходит дольше, чем если это делает система при abort()

2. Во-вторых, если что-то и вправду выполняется долго, то имеет смысл сделать lifecycle, вроде «открывается», «используется», «закрывается», «закрыто». Контроллер мог бы владеть пулом соединений, и управлять выдачей. Соответственно, если какой-то объект требует подключения, то запрашивает контроллер, тот выдает подключение, объект его использует. В деструкторе объект просто отдает подключение контроллеру (вызывает метод «больше не использую»), что быстро, а контроллер в параллель выполняет всю работу по закрытию, не держит деструктор.

Эта модель расширяемая, например, если подключения могут быть открыты до того, как будет использоваться объектами, а процедура открытия длительная, то контроллер может держать определенное количество открытых соединений; тогда выдача будет моментальной; а когда объект отдает соединение, оно может не закрываться, а ждать пока другой объект его запросит. Ну, и контроллировать сколько таких запасных соединений может быть, лишние закрывать. Тогда добавляем lifecycle фазу «не используется».

В книгах написано, что в raii лучшее место для освобождение это деструктор.

Нельзя бездумно использовать фреймворки.
С другой стороны, если фреймворк не подходит, нужно чётко понимать почему. Поэтому меня очень интересует ответ на вопрос 1 выше.

А как синхронизовать время жизни объекта и этого глобального контроллера? Нужно копировать все указатели на выделенные ресурсы?

Давай для начала конкретизируем понятие ресурсов, потому как подходы к памяти, идентификаторам, сокетам могут быть разными.

Мы говорим о соединениях, если я правильно понял.

1. Во-первых, я так и не понял, что входит в понятие «закрыть соединение», и почему это происходит дольше, чем если это делает система при abort()

2. Во-вторых, если что-то и вправду выполняется долго, то имеет смысл сделать lifecycle, вроде «открывается», «используется», «закрывается», «закрыто». Контроллер мог бы владеть пулом соединений, и управлять выдачей. Соответственно, если какой-то объект требует подключения, от запрашивает контроллер, тот выдает подключение, объект его использует. В деструкторе объект просто отдает подключение контроллеру (вызывает метод «больше не использую»), что быстро, а контроллер в параллель выполняет всю работу по закрытию, не держит деструктор.

Эта модель расширяемая, например, если подключения могут быть открыты до того, как будет использоваться объектами, а процедура открытия длительная, то контроллер может держать определенное количество открытых соединений; тогда выдача будет моментальной; а когда объект отдает соединение, оно может не закрываться, а ждать пока другой объект его запросит. Ну, и контроллировать сколько таких запасных соединений может быть, лишние закрывать. Тогда добавляем lifecycle фазу «не используется».

В книгах написано, что в raii лучшее место для освобождение это деструктор.

Нельзя бездумно использовать фреймворки.
С другой стороны, если фреймворк не подходит, нужно чётко понимать почему. Поэтому меня очень интересует ответ на вопрос 1 выше.

А как синхронизовать время жизни объекта и этого глобального контроллера? Нужно копировать все указатели на выделенные ресурсы?

Давай для начала конкретизируем понятие ресурсов, потому как подходы к памяти, идентификаторам, сокетам могут быть разными.

Мы говорим о соединениях, если я правильно понял.

1. Во-первых, я так и не понял, что входит в понятие «закрыть соединение», и почему это происходит дольше, чем если это делает система при abort()

2. Во-вторых, если что-то делается долго, то имеет смысл сделать lifecycle, вроде «открывается», «используется», «закрывается», «закрыто». Контроллер мог бы владеть пулом соединений, и управлять «выдачей». Соответственно, если какой-то объект требует подключения, от запрашивает контроллер, тот выдает подключение, объект его использует. В деструкторе объект просто отдает подключение контроллеру (вызывает метод «больше не использую»), что быстро, а контроллер в параллель выполняет всю работу по закрытию.

Эта модель расширяемая, например, если подключения могут быть открыты до того, как будет использоваться объектами, а процедура открытия длительная, то контроллер может держать определенное количество открытых соединений; тогда выдача будет моментальной; а когда объект отдает соединение, оно может не закрываться, а ждать пока другой объект его запросит. Ну, и контроллировать сколько таких запасных соединений может быть, лишние закрывать. Тогда добавляем lifecycle фазу «не используется».

В книгах написано, что в raii лучшее место для освобождение это деструктор.

Нельзя бездумно использовать фреймворки.
С другой стороны, если фреймворк не подходит, нужно чётко понимать почему. Поэтому меня очень интересует ответ на вопрос 1 выше.