Зачем нужен пакет «net/context»?

Question

[Kagtaviy]

Здравствуйте, прошу прощения за столь наглый вопрос.
Объясните пожалуйста что это за пакет и в каких случаях его нужно использовать?

Answer 1

[spotifi]

Это довольно сложный для понимания пакет.
Не интуитивный.
Вот здесь очень хорошо описано, с расширенными комментариями - а для чего вообще:
https://habrahabr.ru/post/269299/

Answer 2

[Никита]

Вбейте ваш вопрос в гугл, помогает.
Чтение документации иногда полезно, знаете?
https://godoc.org/golang.org/x/net/context
https://blog.golang.org/context

Comments

[spotifi]

Это довольно сложный для понимания пакет.

[Никита]

spotifi: Чего?) Контекст есть везде, зачем его понимать если его назначение очевидно?

[spotifi]

Никита: используешь? ;) там древовидная структура, несколько видов контекста. сплошные интерфейсы. возможность прервать обработку через контекст ;) это не тривиальный контекст.

[Никита]

spotifi: А как без него? 0_о

[spotifi]

Никита: без чего без него? скажем, контекст в Google AppEngine попроще. Более интуитивно понятный. И никакого net/context не нужно было.

В последних версих и туда в примеры начали запихить net/context....

[spotifi]

Никита: В Мартини тоже довольно тривиальный.

[spotifi]

Никита: У Гориллы простой.

[Никита]

spotifi: "используешь? ;)" - Использую, не представляю как без него. В GAPP давно уже net/context, но суть не в этом, как вы контекстно-зависимые данные между модулями передаёте?

[spotifi]

Никита:
Передавать через горилловские, мартиновские - контесты очень просты и интуитивно понятные. Поэтому не проблема их понять и использовать или свой реализовать аналогичный. А вот x/net/context уже не прост в понимании. net/context - не настолько тривиален.

"контесто-зависимые данные между модулями в GAE через x/net/contex"? Они же независимые - там связь только через http.

Вы знаете другой метод? Напряму через контесты? Это интересно. Можно поподробнее?

[Никита]

spotifi: между модулями одной программы, даже зачем так широко между горутинами просто как передать контекстно-зависимые данные и при этом быть уверенным, что основной процесс не закончился?

[spotifi]

Никита: передача между модулями одной программы - тривиальна.

[Никита]

spotifi: Ну да, тривиально передаётся контекст. Или вы знаете другой способ?

[qwex]

Никита: предположим использую gorilla/context.
Я вот не могу понять в каких случаях нужно использовать контекст, вот зачем он вообще нужен. Прошу, объясните своими словами а не посылайте в гугл:3
Заранее спасибо

[Никита]

Валерий Федорченко: а, типо "погуглите за меня"?)
www.gorillatoolkit.org/pkg/context
Там все написано, неужели этого мало?

[spotifi]

Валерий Федорченко:

1. Пришел к тебе запрос (может с внешнего сервиса, с браузера или, может, от части твоей же собственной программы, неважно). Была вызвана какая-то функциюядля обработки, та вызвала еще, та еще, та еще.

2. И где-то там в глубине нужно принять решение - что ответить на запрос. Или, возможно, пора уже отказаться и оборвать (по таймауту например), или тебя снаружи не захотели столько ждать и связь оборвали и тебе не нужно обрабатывать.

3. В контекст складывается вся информация, которая нужна для обработки, для принятия решения. Иногда - там же обрывается соединение. Но прежде всего контекст - это куча информации.

4. Как правило эту информацию может в контекст положить самая первая, верхняя функция - обязательно. Вложенные функции - могут дополнять контекст.

5. Где-то в самом низу, в самой глубоко вложенной функции тебе как на блюдечке в контексте лежит куча информации для принятия решения.

6. Можно это делать и просто прокидыванием переменных внутрь. Но с каждым уровнем число переменным может возростать.

7. Контекст - не то чтобы заведомо удобнее, но всяко-разно универсальнее. Хотя для простых случаев я бы обошелся без него. С ним все таки не очень удобно. Например, типичным для контекстов является сохранение значений в map[string]interface{}, что лишает тебя возможности проверки типов на этапе компиляции. Так что в простых случаях можно обойтись без этого, вместо контекста использовать переменные вполне определенные и вполне определенных типов - будет надежнее работать. Но в сложных случаях этих переменных будет слишком много, они могут быть разных типов, не все из них будут всегда использоваться, поэтому вариант map[string]interface{} и используется зачастую.

7. В случае с /x/net/context - это используются интерфейсы, что делает его вроде менее очевидным, но более типобезопасным. В статье https://habrahabr.ru/post/269299/ описано немного какие есть альтернативные представления контекстов. Все они - проще для понимания, более тривиальны, подобны обычному map[string]interface{}. Но этот контекст хоть и более мозгодробительный, но более надежный, так как часть ошибок вылавливает компилятор.

8. Типичное использование в веб-приложениях к примеру (можно и не только в веб-приложениях, но это я к примеру) - изначально кладем туда данные запроса, лучше слегка обработанные. "/api/v1/labuda/123" - например RESTful API - получение labuda #123 - кладем в контекст объект Labuda{}, на следующем уровня в контекст вкладывается объект DatabaseConnection, а в самом низу извлекаем данные пользуясь DatabaseConnection и кладем их в Labuda{}, результат так же через контекст возвращается наверх.

[spotifi]

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

В монолитной системе - это можно было бы хранить более глобально и заполнять только при запуске.

Answer 3

[alex08]

Вот хороший перевод: poetofcode.ru/2016/01/09/patternyu-parallelizma-v-...

Answer 4

[ilyasvetozar]

Это типа контейнера или буфера для хранения промежуточных данных.
Встроенный сервер Go обрабатывает запросы параллельно. Поэтому например, внешние от функции, переменные могут использоваться одновременно несколькими потоками. Если идет цепочка функций то надо передавать в качестве аргумента данные, что неудобно.
Фреймворки предлагают свои контексты(контейнеры), теперь с версии 1.7 контекст имеется в стандартной библиотеке.