Size: a a a

2020 October 02

A

Aikidos in Go-go!
Rokker Ruslan
Ну тут очень просто на самом деле. Откатимся на частый пример использования, у нас есть сервер, вы приняли запрос, обрабатывая его вы взяли сущность из пула, завершили обработку - положили в пул. Теперь чуть сложнее, есть сервер, вы приняли запрос, взяли сущность из пула, для его дополнительной обработки вы отдали сущность в горутину (n горутин). Горутины завершаются, какая из них должна положить сущность обратно в пул?

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

Мы взяли сущность и отдали её N-горутинам. Почему горутины должны думать, как положить её обратно в пул? У нас в коде, как пример, правило, кто взял, тот и положил. Кто открыл соединение, тот и закрыл и всё в этом духе.

Расскажите подробнее.
источник

RR

Rokker Ruslan in Go-go!
По порядку. Контекст взявший объект из пула завершается. Он не может положить объект обратно в пул, так как есть другие контексты его использующие. Объект продолжает жить.  Зафиксировали?
источник

RS

Rusty Shackleford in Go-go!
Ощущение словно вы хотите семафор. Но тут скорее не понятно, зачем отдавать один объект из пула N потокам, вся суть пула теряется.
источник

RR

Rokker Ruslan in Go-go!
И тут можно ещё немного обобщить, контексту не обязательно завершаться, просто объект в какой то момент времени станет контексту не нужен. Но положить в пул он его не может. И не кладёт.
источник

DP

Daniel Podolsky in Go-go!
коллега
источник

DP

Daniel Podolsky in Go-go!
почему у вас один объект из пула шарится между разными горутинами? чтобы что?
источник

RR

Rokker Ruslan in Go-go!
Потому что объект нужен разным горутинам.
источник

DP

Daniel Podolsky in Go-go!
скорее всего - это вы плохо продумали архитектуру.
источник

DP

Daniel Podolsky in Go-go!
вот скажите - какую проблему решает пул?
источник

RR

Rokker Ruslan in Go-go!
Избежать аллокации.
источник

DP

Daniel Podolsky in Go-go!
а почему ее надо избегать?
источник

RR

Rokker Ruslan in Go-go!
Daniel Podolsky
скорее всего - это вы плохо продумали архитектуру.
Возможно, но я ведь не про архитектуру, я про подсчёт ссылок.
источник

DP

Daniel Podolsky in Go-go!
(это треть ответа примерно - избежать аллокации)
источник

DP

Daniel Podolsky in Go-go!
Rokker Ruslan
Возможно, но я ведь не про архитектуру, я про подсчёт ссылок.
не надо решать несуществующие проблемы
источник

RR

Rokker Ruslan in Go-go!
Daniel Podolsky
не надо решать несуществующие проблемы
Поясните.
источник

DP

Daniel Podolsky in Go-go!
скорее всего - вам не надо шарить объект из пула между горутинами
источник

RR

Rokker Ruslan in Go-go!
Пожалуйста, не надо этих слов. Мы говорим не о применимости решения в каком либо случае, а о решении как таково. Я не говорил где мы используем и это не имеет значения.

Мы говорим о подсчёте ссылок. Это не редко используемый подход и не мы его придумали. Можете ознакомиться со сферами применения по статье https://en.m.wikipedia.org/wiki/Reference_counting И говорим именно про его возможную реализацию в го. Только и всего.
источник

RR

Rokker Ruslan in Go-go!
Это я немного не с того зашёл и спутал скорее всего. Правильно было бы задать вопрос именно так: ребята как вы реализовывали подсчет ссылок в го. Ответить на него очевидно могут те, кто этот подход использовал.
источник

DP

Daniel Podolsky in Go-go!
подсчет ссылок в go реализован в рамках GC
источник

RR

Rokker Ruslan in Go-go!
Я очевидно что-то не так объяснил. Но в статье http://www.hydrogen18.com/blog/reference-counted-pool-golang.html описывается именно то, что хотел донести тут. Предлагаю ознакомиться с первой её частью. Она совсем небольшая. Правда, прочтите.
источник