конечно, со структурами этого нет. там вообще нет контроля доступа

коллеги, ну вот хоть чуть-чуть знать свои инструмент надо, правда?

я знаю. другой вопрос, что в рантайме много проверок на крайне низкочастотные случаи, поэтому со 100% уверенностью говорить об отсутствии таких проблем со структурами я не могу

а почему в map есть такая проверка - ты знаешь?

да

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

а я не говорил о том, что там причины и проверки одинаковые

вот именно там никаких проверок нет

ты уже везде посмотрел? очень быстро.

я никуда не смотрел

создатели языка довольно логичны, и логика их мне понятна

твоя, кстати, нет

зачем нужен thread safe map?

я никуда не смотрел

тогда стоит помнить кучу паник с текстом типа "никогда не должно произойти".

зачем нужен thread safe map?

производительность, например

в смысле - она слишком высока, надо уменьшить?

ни в коем случае. она слишком низка, надо увеличить.

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

и как ее можно увеличить с помощью thread-safe?

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

+1

просто потому что бесплатного ничего не бывает

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

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

ну в одном случае "не вызвана" в другом случае "ее нет" второй случай быстрее )

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

ну в одном случае "не вызвана" в другом случае "ее нет" второй случай быстрее )

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

так не бывает

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

если че -- я говорю про случай "в один поток"

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

серьёзно, я сделаю бенчмарки и будете смотреть сами.

ну да

вот да, и еще сделаем собственные

вот да, и еще сделаем собственные

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

кстати, надо будет всё таки запушить реализацию.

давно пора

А память сразу отводится под массив?

если указать capacity, то сразу выделяется, сколько попросили

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

кто нибудь формировал Request c 'Content-Type: multipart/form-data ?

а в чем сложность?

boundary=---------------------------100461727514195' как генерировать?

кто нибудь формировал Request c 'Content-Type: multipart/form-data ?

http://stackoverflow.com/questions/20205796/golang-post-data-using-the-content-type-multipart-form-data

а зачем так сложно, есть же https://golang.org/pkg/net/http/#Client.PostForm

или я не о том?

а зачем так сложно, есть же https://golang.org/pkg/net/http/#Client.PostForm

The Content-Type header is set to application/x-www-form-urlencoded.

а, да, не о том ))) невыспался, что называется )))

:)

А если с помошью http.NewRequest и req.Header.Add собирать?

А если с помошью http.NewRequest и req.Header.Add собирать?

Пример с stackoverflow внимательно читали? Там Request так и собирается.

Зачем multipart? Избегайте его по возможности

Зачем multipart? Избегайте его по возможности

да это для бота, запросы слать

@pragus Почему нужно по возможности избегать multipart?

@pragus Почему нужно по возможности избегать multipart?

Музыка у тебя сложная.

Если серьезно, то там надо долго сканить до boundary

И это дорого

хм... пока мало что ясно, но я запомню про "долго сканить до boundary". Спасиб.

если тело запроса не супер жирное то и мультипарт ок

если тело запроса не супер жирное то и мультипарт ок

А если это dvd.iso? :)

хорошо, а как в случае двд.исо поступать?

А если это dvd.iso? :)

см выше, dvd.iso это уже большой запрос, далеко не всем надо гонять такие объемы

хорошо, а как в случае двд.исо поступать?

данные в body as-is

данные в body as-is

так себе решение

хорошо, а как в случае двд.исо поступать?

http put

так себе решение

Альтернативы?

так себе решение

почему?

ERROR: S client not available

докачка, градусник

докачка, градусник

докачку заголовком

А что, ренджи в докачке нельзя?

можно

все можно

никто не говорит что это идеальное решение просто остальные - хуже

http put

Проведи ликбез. А разве спецификация вообще устанавливает содержание BODY в зависимости от методов? Ткни мне носом

Проведи ликбез. А разве спецификация вообще устанавливает содержание BODY в зависимости от методов? Ткни мне носом

Да тот же get

Там нет body

Да тот же get

Ткни меня носом, где спецификация оговаривает его Body

P.S. Я даже верю, что оговаривает. Но например прошлый мой заход в исследования выдал мне пачку открытий чудных, типа отстутствия как класс QUERY_STRING :)

Сейчас ты говоришь, что в PUT есть какие-то ограничения на Body. У меня возникли сомнения

Ткни меня носом, где спецификация оговаривает его Body

http://stackoverflow.com/questions/5216567/is-this-statement-correct-http-get-method-always-has-no-message-body

http://stackoverflow.com/questions/5216567/is-this-statement-correct-http-get-method-always-has-no-message-body

Спасибо. RFC такие RFC всегда. Т.е. прямого запрета нет судя по всему

Вернемся к PUT

Фил, формально ты прав. на практике - почти всегда в POST при аплоаде пихают multipart

Всем привет. А есть кто на го с тарантул работал?

Фил, формально ты прав. на практике - почти всегда в POST при аплоаде пихают multipart

погодь. у тебя curl. ты как пихнешь, так и будет. судя по твоей ссылке он даже в GET пихнет и не подавится. а PUT вообще никто не использует не специально

погодь. у тебя curl. ты как пихнешь, так и будет. судя по твоей ссылке он даже в GET пихнет и не подавится. а PUT вообще никто не использует не специально

угу.

Там нет body

как бы его там не было но потом все начали поддерживать

и поддерживают

как бы его там не было но потом все начали поддерживать

угу. я ж говорю - на практике кто в лес, кто по дрова.

кстати, для sha1 в go есть ассемблерная вставка для i386/amd64/avx2

https://godoc.org/github.com/thejerf/suture

At the kernel level, user IDs and group IDs are a per-thread attribute. However, POSIX requires that all threads in a process share the same credentials. The NPTL threading implementation handles the POSIX requirements by providing wrapper functions for the various system calls that change process UIDs and GIDs. These wrapper functions (including the one for setuid()) employ a signal-based technique to ensure that when one thread changes credentials, all of the other threads in the process also change their credentials.

Почему возникает такая ошибка? msgpack: Decode(nonsettable []main.Status) вроде бы все зарегестрировал msgpack.Register(reflect.TypeOf([]Status{}), encodeAllStatus, decodeAllStatus)

имеет ли значение если я буду серверу отправлять multipart/form-data с boundary вида "--6ce92856b1e41ff4a0d62e94587dc8c7d3832bf7f975900e00431abc4739" вместо "-----------------------------15592920719210" как сейчас сделано на сайте?

не имеет

имеет ли значение если я буду серверу отправлять multipart/form-data с boundary вида "--6ce92856b1e41ff4a0d62e94587dc8c7d3832bf7f975900e00431abc4739" вместо "-----------------------------15592920719210" как сейчас сделано на сайте?

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

ок, спасибо

Почему возникает такая ошибка? msgpack: Decode(nonsettable []main.Status) вроде бы все зарегестрировал msgpack.Register(reflect.TypeOf([]Status{}), encodeAllStatus, decodeAllStatus)

А вызываешь как? с адресом слайса?