(As an aside, there is a well-known gotcha in Java and other languages that when you slice a string to save a small piece, the reference to the original keeps the entire original string in memory even though only a small amount is still needed. Go has this gotcha too. The alternative, which we tried and rejected, is to make string slicing so expensive—an allocation and a copy—that most programs avoid it.)

что компилятору мешает сначала скопировать объект, а потом уже делать обрезку

где хранить пул коннектов? вот у меня есть пакет database, в нем есть connect() который устанавливает соединение и Get() который возвращает *sql.DB, это нормалная реализация? Или нужно делать вот эту структуру с Env: куда ложить логгер, db, и прочее?

sync.Pool, не ?

пул коннектов я имею ввиду sql.DB, там же внутри есть уже пул

короче, где хранить *sql.DB

вот что я хотел узнать)

где хранить пул коннектов? вот у меня есть пакет database, в нем есть connect() который устанавливает соединение и Get() который возвращает *sql.DB, это нормалная реализация? Или нужно делать вот эту структуру с Env: куда ложить логгер, db, и прочее?

Глобальную переменную типа *sql.DB, в этом пакете установить соединение и везде пользоваться, чем плохо? Зачем Get?

ну т.е., у меня есть хендлеры, и в них передавать *sql.DB? а чем плохо database.Get().Query() делать?

ну или database.Get() и погнал

пул коннектов я имею ввиду sql.DB, там же внутри есть уже пул

Есть, и установить ограничения сразу, чтобы базу на отторжение лишних не наталкивать

короче, где хранить *sql.DB

Вот образец, за код не пинать, первая прожка на го. https://github.com/MarlikAlmighty/examplefasthttp

Зачем Get? database.DB.Query()

Зачем Get? database.DB.Query()

ну а инициализацию как сделать? Допустим, база ещё не поднялась. но приложуха уже должна что-то отвечать

пока sql.Open() поинтер будет нил, и потом будет race condition

Есть init

init блочит же

Инит лучше не юзать.

init блочит же

где можно поподробней почитать?

Инит, да, плохо. Или заранее, прочитать конфиг, соединение с базой сделать

где можно поподробней почитать?

напиши в init time.Sleep(time.Second * 60)

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

И пока прога не проинициализируется, нахрена ей отвечать что-то?

И пока прога не проинициализируется, нахрена ей отвечать что-то?

потому что коннекты собираются в очередь

она должна отвечать ошибкой и не копить их, ну или копить пока не треснет

Нихрена не понял, у тебя нет соединения с базой, нет ничего, но уже есть коннекты?

ну да, люди долбят сайт

ну да, люди долбят сайт

Пока с базой не соединишься никуда всё-равно не поедешь

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

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

Те кто долбят моргнуть не успеют как это всё произойдёт

Или база на марсе?

проблема в том, что если база упала, а перед Go нету ничего (например, Nginx), то сайт будет валяться как труп

нужно отобразить какую-то ошибку

если ставишь вперед nginx

то он копит в пул соединения, если твой сокет или порт начинает отвечать

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

Ну дык если упала база, фактически и бэкенд накрылся, тада фронтенд должен ошибку отобразить.

тогда nginx будет отрисовывать ошибки

Какой пул?

Нет базы после старта, отвечай 500

Но коннект уже настроен, он будет реконектиться сам

Каждый день удивляюсь предметам спора в этом чате

Я ж ведь даже и не спорил

Вопрос изначально был о том, где хранить *sql.DB. В init() не вариант. Прямой доступ тоже как-то плохо. Что мешает где-то по тупняку сделать db = nil? Делаем Get() возвращающий поинтер на *sql.DB и connect() который коннектится к базе и подменяет поинтер через atomic.SwapPointer, чтобы гонки не было. Или я не прав?

Это даже лучше не слушать пока все инициализации не пройдут. Человек открывает страницу, а у него полосочка загрузки начинает медленно передвигаться, он не уходит пока у тебя приложуха стартует, секунд 20 ждёт, энжи также делает прежде чем 500 отдать. Потом у тебя запустился сервер и всем отдал инфу. А если ты сразу всем отдашь 500, а потом начнёшь конфиг читать, не все вернутся потом за инфой. Да и порт на котором принимать запросы разве не в конфиге?

Вопрос изначально был о том, где хранить *sql.DB. В init() не вариант. Прямой доступ тоже как-то плохо. Что мешает где-то по тупняку сделать db = nil? Делаем Get() возвращающий поинтер на *sql.DB и connect() который коннектится к базе и подменяет поинтер через atomic.SwapPointer, чтобы гонки не было. Или я не прав?

Там всё продумано, не нужен атомик!

И ты перед каждым запросом коннект типа поднимаешь?

мда, записывайтесь к Василию на курс вообщем

И больше не ешь эти грибы

Интересный вопрос. Если я в переменной храню указатель и в миллионе горутин его читаю, но только в одной пишу. При этом мне не важно прочитался старый указатель или новый. Состояние гонки может повредить указатель при одновременном чтении и записи и надо лочить?

go-database-sql.org вот это хорошо читать

go-database-sql.org вот это хорошо читать

Лучше вообще про рейсы почитать, наверно

Лучше вообще про рейсы почитать, наверно

Это я про предыдущую тему о базе

Интересный вопрос. Если я в переменной храню указатель и в миллионе горутин его читаю, но только в одной пишу. При этом мне не важно прочитался старый указатель или новый. Состояние гонки может повредить указатель при одновременном чтении и записи и надо лочить?

Мне товарищи сишники утверждали, что лочить не надо и система сама разберется, но они были пьяны и я им не доверяю.

В гошечке одновременное чтение будет тебе триггерить варнинги про рейсы и у тебя твои миллион горутин повесят нахрен все)

Интересный вопрос. Если я в переменной храню указатель и в миллионе горутин его читаю, но только в одной пишу. При этом мне не важно прочитался старый указатель или новый. Состояние гонки может повредить указатель при одновременном чтении и записи и надо лочить?

Не успеет, скорее всего, паника будет

Это я про предыдущую тему о базе

Прошу прощения, не там пальцем провел) это на сообщение выше писал

Короче, надо навернуть атомик, ок

Пойду попробую вызвать панику при смене указателя

В вашем случае sync.RWMutex

Если большинство читает

И то верно

Пойду попробую вызвать панику при смене указателя

В любом случае хорошее правило - если читает/пишет больше одного, то мьютекс

Но все же. https://4gophers.ru/articles/konkurentnost-v-go-gonki/

Вот в статье пример, где программа с состоянием гонки не вызывает панику

(при этом, в моём вопросе не имеет значения корректность результата)

Значит ли это, что можно не заморачиваться с синхронизацией?)

Значит ли это, что можно не заморачиваться с синхронизацией?)

Гонка не вызывает панику, она вызывает непредсказуемое поведение приложения, что намного хуже чем паника.

Гонка не вызывает панику, она вызывает непредсказуемое поведение приложения, что намного хуже чем паника.

Я же говорю, что меня устраивает, что будет прочитан старый указатель. Это (для меня) предсказуемое поведение.

Тогда пожалуйста

И ты перед каждым запросом коннект типа поднимаешь?

С чего это вдруг? Речь идет вот о чем: 1. Пришел запрос от клиента, берем наш *sql.DB 2. В это время наша горутина устанавливает коннект и в переменную database.DB пишет то, что вернул sql.Open. Что это? Не гонка разве?

Я же говорю, что меня устраивает, что будет прочитан старый указатель. Это (для меня) предсказуемое поведение.

Это пока устраивает. А потом не будет устраивать, но забудется и придется искать причину ошибки. Так что лучше сразу нормально сделать.

С чего это вдруг? Речь идет вот о чем: 1. Пришел запрос от клиента, берем наш *sql.DB 2. В это время наша горутина устанавливает коннект и в переменную database.DB пишет то, что вернул sql.Open. Что это? Не гонка разве?

Блин, нет, там внутри пул из этих коннектов

Какая разница что там внутри

Это пока устраивает. А потом не будет устраивать, но забудется и придется искать причину ошибки. Так что лучше сразу нормально сделать.

+

это был вам намёк, что делом надо заниматься, а не призрачный тест кавердж блюсти

возможно, но удобно видеть, когда вдруг какой-то тест случайно оторвал

Какая разница что там внутри

Ты ещё мутексы мутексами оборачивай

sql.Open() возвращает у тебя в DB, в этот момент ты берешь database.DB и обращаешься к нему.

объясните ему кто-то

когда коннект установился, понятно что внутри concurrent safe

Это пока устраивает. А потом не будет устраивать, но забудется и придется искать причину ошибки. Так что лучше сразу нормально сделать.

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