Господа, нужно, что бы при запуске программы, если загрузка цп высокая, она ожидала снижения и только тогда исполнялась Чего то не получается примеров нагуглить, может кто ткнет?

Господа, нужно, что бы при запуске программы, если загрузка цп высокая, она ожидала снижения и только тогда исполнялась Чего то не получается примеров нагуглить, может кто ткнет?

man nice

это неэффективно.

bits.OnesCount в помощь

вот так проще проверять: n & (n-1) == 0

https://play.golang.org/p/vq1NhsoxgnT

https://play.golang.org/p/vq1NhsoxgnT

good!? Отличный вариант

хотя вот так быстрее - https://play.golang.org/p/z3bVJO8z6Z8 .

нет проверял через bitsOneCount проигрывает даже моему варианту , а твой первый выигрывает у моего

хотя вот так быстрее - https://play.golang.org/p/z3bVJO8z6Z8 .

странно, твой вариант с битовыми операциями быстрее на amd64

https://play.golang.org/p/vq1NhsoxgnT

пасибки☺️

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

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

https://play.golang.org/p/of5oLLYVIBx

goos: linux goarch: arm64 BenchmarkIsStepen-4 30000000 41.7 ns/op BenchmarkIsPowerOfTwoPopCnt-4 1000000000 2.62 ns/op BenchmarkPowerOfTwo-4 1000000000 2.62 ns/op PASS

goos: linux goarch: amd64 BenchmarkIsStepen-4 200000000 7.92 ns/op BenchmarkIsPowerOfTwoPopCnt-4 2000000000 0.68 ns/op BenchmarkPowerOfTwo-4 2000000000 0.34 ns/op PASS

убираю свое как не оптимальное?

себе в копилку Александра

Ребят, подскажите по github. Был проект оригинальный, я его форкнул, сделал изменения, отправил pull request. Дальше я сделал еще изменения в моем форке и хочу отправить второй pull request как это сделать? И всё ли я правильно делаю

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

Сделать агрегатор, который блкирующе по очереди читает из каналов, куда пишут горутины

Сделать агрегатор, который блкирующе по очереди читает из каналов, куда пишут горутины

Тогда на каждую горутину нужен отдельный канал?

Да

Тоже вариант, но я хотел как-то одним каналом обойтись, боюсь что много каналов слишком затратно по памяти

Но тоже вариант

убираю свое как не оптимальное?

Вообще, popcnt есть почти везде и это инструкция исполняется 1 такт

man nice

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

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

Куда записался?

Тоже вариант, но я хотел как-то одним каналом обойтись, боюсь что много каналов слишком затратно по памяти

А чем массив не нравится?

Или слайс

Куда записался?

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

Хотя можно же на вызов горутины добавлять элемент в слайс и передавать его как замыкание

Вообще, popcnt есть почти везде и это инструкция исполняется 1 такт

да на fasm писал когда не было поддержки этой инструкции , спасибо за информацию

пошел изучать math.bits

хотя из жизненного там только OnesCountХХ и LenXX , все равно еще раз пасибки

Задача в чем?

Разбить прото файлы на более мелкие

Разбейте. Оно нагенерит go файлов по числу прото файлов

Разбейте. Оно нагенерит go файлов по числу прото файлов

Как они будут потом подключать друг друга?

Плохой вопрос

Насколько я знаю, golang не может подключать пакеты по относительному пути (если находится по пути GOPATH'а). Когда разбиваются прото файлы на несколько и подключаю их в в других - пишет ошибку только для golang'a

Невозможно ответить

Зачем вам связанные прото разносить по директориям

Насколько я знаю, golang не может подключать пакеты по относительному пути Может

import берет из GOPATH/src что угодно

будь то хоть "fuckyou/idiot"

Зачем вам связанные прото разносить по директориям

Чисто для удобного добавления/удаления/редактирования в дальнейшем. Детальней можно прочитать что мне нужно здесь - https://stackoverflow.com/questions/52914402/compile-multiple-proto-files-into-single-file

Или они не связаны, или их нельзя редактировать отдельно

Или они не связаны, или их нельзя редактировать отдельно

Немного не понял ответа. Есть сервис User (для работы с пользователями) - в котором есть entry (логин, регистрация) и info (информация о пользователе). Я хочу разбить эти две логики на более маленькие прото файлы, так как их будет намного (намного) больше

Зачем по разным директориям их разносить?

Это все что нужно. Понимаю, что можно оставить все в одном файле user.proto, но очень не хотел бы это делать

Зачем по разным директориям их разносить?

Нет, нет. Директория одна

Тогда оно все найдет и сгенерит

Доберусь до компа - пришлю пример

Доберусь до компа - пришлю пример

Но, тем не менее, у меня оно пытается подключить. Буду весьма признателен

в большинстве компаний скорее ситуция похожа на "стая гоферов бежит за человеком у которого в руках Python/Ruby/JavaScript" причём гоферы с копьями

На сколько я понял, через WriteAt можно писать разные части файла одновременно, если они не пересекаются, а для этого дескриптор должен быть один? Например если я хочу параллельный аплоад файла кусками сделать, то надо сохранять дескриптор, что бы можно было в него писать? И как правильнее будет тогда записывать в файл, буферизировать в память кусками из входящего потока и через WriteAt писать или есть какой-то аналог io.Copy с возможностью указания с какого места писать?

На сколько я понял, через WriteAt можно писать разные части файла одновременно, если они не пересекаются, а для этого дескриптор должен быть один? Например если я хочу параллельный аплоад файла кусками сделать, то надо сохранять дескриптор, что бы можно было в него писать? И как правильнее будет тогда записывать в файл, буферизировать в память кусками из входящего потока и через WriteAt писать или есть какой-то аналог io.Copy с возможностью указания с какого места писать?

а зачем тебе несколько дескрипторов?

а зачем тебе несколько дескрипторов?

Ну допустим у меня приходит http запрос с куском файла и range например 100-200 и в это же время в другом хендлере в этот же файл пишется 0-99 кусок.

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

Ну да, но если я в двух хендлерах вызову os.OpenFile на один и тот же файл и буду в него писать разве это будет работать?

Ну допустим у меня приходит http запрос с куском файла и range например 100-200 и в это же время в другом хендлере в этот же файл пишется 0-99 кусок.

можешь сделать так: 1. структуру менеджмента файлов, которая отвечает за открытие, закрытие и т.п. 2. структуру файла, которая отвечает за буферезацию и синхронизацию (мутекс для синхронизации и fd)

3. интерфейсы для работы с этими сущностями

Ну примерно так и думал. А вот на счет записи через WriteAt есть какой-то способ не буферизовать в память? Вроде io.Copy напрямую как-то писать может...

Ну да, но если я в двух хендлерах вызову os.OpenFile на один и тот же файл и буду в него писать разве это будет работать?

работать по сути должно, но это очевидный data race, хотя я не совсем уверен сможешь ли ты его вообще несколько раз открыть для записи (ведь по сути файловая система ОСи накладывает на fd lock, но если я не ошибаюсь лок ассоциируется с процессом, поэтому „по сути“ один и тот же процесс „по сути должен“ суметь открыть файл несколько раз (но я не уверен, нужно проверять, ибо тут ещё go runtime в игре между ОСью и кодом))

работать по сути должно, но это очевидный data race, хотя я не совсем уверен сможешь ли ты его вообще несколько раз открыть для записи (ведь по сути файловая система ОСи накладывает на fd lock, но если я не ошибаюсь лок ассоциируется с процессом, поэтому „по сути“ один и тот же процесс „по сути должен“ суметь открыть файл несколько раз (но я не уверен, нужно проверять, ибо тут ещё go runtime в игре между ОСью и кодом))

ошибаешься, ОС так не делают

но даже если и не открывать несколько раз - file descriptor это по факту указатель, если из нескольких горутин с файлом работать тогда очевидно нужна синхронизация

ошибаешься, ОС так не делают

ты уверен? надо конечно проверить, но я предполагаю что открыть из нескольких процессов один и тот же файл на запись - не получится, хотя…. хер его знает

ты уверен? надо конечно проверить, но я предполагаю что открыть из нескольких процессов один и тот же файл на запись - не получится, хотя…. хер его знает

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

ты уверен? надо конечно проверить, но я предполагаю что открыть из нескольких процессов один и тот же файл на запись - не получится, хотя…. хер его знает

PID один и дескриптор один(винда)

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

ну эт на линуксе, а я мыслю кросс-платформенно, не охота же чтоб на одной ОСи софт работал эдак а на другой иначе?

ну эт на линуксе, а я мыслю кросс-платформенно, не охота же чтоб на одной ОСи софт работал эдак а на другой иначе?

это твоя задача обеспечить синхронизацию

это твоя задача обеспечить синхронизацию

про синхронизацию то понятно) я так и написал, что синхронить самому

про синхронизацию то понятно) я так и написал, что синхронить самому

ну ОС за тебя это делать не факт что будет

команда WriteAT не говорит о каких либо различных дескрипторах файла не придумываейте и множестеннных Open

ну ОС за тебя это делать не факт что будет

нее, не синхронизацию, а защиту от открытия в экслюзивном режиме записи разными процессами

но я чес. гря. не уверен имеет ли go runtime тут какую-то прослойку при работе с файлами

но я чес. гря. не уверен имеет ли go runtime тут какую-то прослойку при работе с файлами

Го при открытии делает RDONLY

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

@Romshark если ты делаешь именно O_RDWR | O_EXCL - тогда да, на запись не откроешь еще, но это твоя задача так делать

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

не люблю я каналы, честно говоря. Я бы обернул файл в структуру с fd и mutex’ом, описал методы и всё это дело обернул в интерфейсы

Интересно, как сервисы, типа всяких вконтактиков аплоад делают, там как раз в несколько потоков файлы льются на сервер.

не люблю я каналы, честно говоря. Я бы обернул файл в структуру с fd и mutex’ом, описал методы и всё это дело обернул в интерфейсы

Ну тоже вариант...

не люблю я каналы, честно говоря. Я бы обернул файл в структуру с fd и mutex’ом, описал методы и всё это дело обернул в интерфейсы

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

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

когда будете закрывать файл?

грейсфул нужно

когда будете закрывать файл?

Когда все хендлеры перестанут в него писать. То есть в каждом хендлере инкремент счетчика и по defer декремент.

Когда все хендлеры перестанут в него писать. То есть в каждом хендлере инкремент счетчика и по defer декремент.

а когда хендлеры закончат?

@Romshark если ты делаешь именно O_RDWR | O_EXCL - тогда да, на запись не откроешь еще, но это твоя задача так делать

Не нашел в мане такой комбинации

Не нашел в мане такой комбинации

а она есть

а когда хендлеры закончат?

Когда входящее соединение отдаст все, что принесло.

Для каждого из хендлеров.

а она есть

 If O_EXCL is set and O_CREAT is not set, the result is undefined.

Если придет новый запрос, то снова открывать файл.

Дабл ять

Замеморимаппьте файл и пишите куда хотите

На 64 битах похер на размер же