нет, хттп-сервер стандартный.

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

кек

типичная xy problem

принимающих рутин порождается столько, сколько получится. А обрабатывающих и отвечающих - только столько, сколько CPU

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

это вебсокеты.

Почему на Go не пишут СУБД для самого Го ?

https://github.com/boltdb/bolt

ну тогда речь идет о написании твоего хттп сервера. причем тут стандартный?

да нет тут в коде своего хттп сервера...

это вебсокеты.

а, я понял, и типа приходят сообщения и ответ будет когда будет, не обязательно по порядку

если кто-то поймет о чем речь, то, пожалуйста, напишите. потому что это какой-то оксюморон идет уже

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

тем более что просто мьютекс работает в разы быстрее канала

а, я понял, и типа приходят сообщения и ответ будет когда будет, не обязательно по порядку

да, ответ будет тогда, когда мы осилим.

есть смысл задуматься

Мьютекс позволяет работать только кому-то одному. А у нас запросы могут приниматься пиково тысячами, а обрабатываться фиксированным числом воркеров.(внутри воркеров, конечно тоже есть мьютексы на некоторых операциях, но это уже другое)

не шарите, как каналы внутри работают

канал по сути и есть очередь с мьютексом

только один из неё или достаёт или кладёт

мьютекс не надо держать всё время обработки

только запись/чтение из канала - это очень короткая операция. Надолго в ней застрять нельзя.

только когда обмен идёт

готовая реализация https://github.com/phf/go-queue

только запись/чтение из канала - это очень короткая операция. Надолго в ней застрять нельзя.

взять/записать значения в канале параллельно нельзя, там тоже мьютекс

можно ресайзить

правда удобную работу с селект-ом без каналов не сделать

потому что го так завязан

я думаю лучше всего вот как сделать

действительно ставить в очередь через канал

а там уже перегружать в какую-нить очередь на связанных списках

а с другого конца выбирать из этой очереди и засыпать, если очередь пустая пока новой задачей не разбудят

https://pkg.go.dev/github.com/antigloss/go/concurrent/container/queue#LockfreeQueue

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

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

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

но без селектов (грустит)

так ты можешь вытаскивать из очереди каким-то циклом и так же в канал класть

главное чтобы вот этот кусок посередине был "резиновый"

да, все это можно. Но это все сложнее, чем мечтать о каналах переменной длины )

а там уже перегружать в какую-нить очередь на связанных списках

зачем связанные списки?

вообще мьютекс можно заменить каналом с буфером 1, и тогда селекты будут работать

зачем связанные списки?

предлагаете массив ресайзить?

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

связанный список же плохой по отношении к памяти объект

фишка в том, что ты можешь вставить в любое место или извлечь элемент из любого места, а если из начала и конца забирать, то зачем?

фишка в том, что ты можешь вставить в любое место или извлечь элемент из любого места, а если из начала и конца забирать, то зачем?

чтобы не ресайзить как раз. если элемент-член очереди формируется и передаётся откуда-то, то дешевле слинковать указатели, чем копировать

слишком дорого это с точки зрения кэша и GC

указатели за долгое время работы программы так засрут и фрагментируют память, что никакой GC не справится. Разве что элементы списка выделять не в куче, а в каком-то реюзабельном пуле

указатели за долгое время работы программы так засрут и фрагментируют память, что никакой GC не справится. Разве что элементы списка выделять не в куче, а в каком-то реюзабельном пуле

што

надо их запретить тогда

ох уж эти указатели

ох уж эти указатели

в питоне такой фигни нет

если ctypes не трогать да

привет всем done := make(chan bool) fmt.Println(*done) вот так не могу получить false потому что это канал а не pointer ?

а причём тут поинтер вообще?

ну и операция чтения из канала должны быть: <-done

хорошо, смотри если я сейчас сделаю fmt.Printf("%v", done) что то типа 0xc0000220c0 получу, а это название ячейки

я думаю, ты получишь название типа

ой нет не %T а %v

хорошо, смотри если я сейчас сделаю fmt.Printf("%v", done) что то типа 0xc0000220c0 получу, а это название ячейки

Если ты так же сделаешь для интерфейса ты тоже получишь указатель

то что ты получишь при форматировании в строку - не показатель, чем этот тип является для го

Что ?? Хорошо, по другому 0xc0000220c0 —-> вот это кроме названии ячейки еще что то может быть ?

Что ?? Хорошо, по другому 0xc0000220c0 —-> вот это кроме названии ячейки еще что то может быть ?

А ты посмотри что из себя представляет канал под капотом

понял, пойду тогда дальше читать )

/settings@SimpleCleanup_bot

Бля куда я нажал

ГОГООО СПИДРАН ПО БАНУ

/ricardo

F

еще один

Чо рили забанило?

зачем...

?

Бля

Чзх

эээээ

Зачем?