type Peoples struct { one map[string]string two map[string]string mutexOne sync.RWMutex mutexTwo sync.RWMutex }

@Civiloid делай рукалицо )))

People - уже множественное

@rsaoskol сделай: type SyncedMap struct { sync.RWMutex data map[string]string } type People struct { one SyncedMap two SyncedMap }

тогда у тебя будет семантика: People.one.Lock() People.one.data["foo"] = "bar" People.one.Unlock()

и это более логично и ожидаемо

или посмотри на sync.Map сразу

я встречал в коде, когда просто, без структуры идут var ( somevalue sometype mutex sync.Mutex ) интересно, а что лочится в данном случае?

забыл добавить, что видел такое в пакете main

я встречал в коде, когда просто, без структуры идут var ( somevalue sometype mutex sync.Mutex ) интересно, а что лочится в данном случае?

лочится всё, что вызовет второй lock мутекса вроде

ага

забыл добавить, что видел такое в пакете main

Если в main(), то, думаю, там лочится вся прога, пока не поступит оплата от заказчика в полном объёме.

хм, странно, вроде там ничего колом не вставало, просто академический интерес, спасибо )))

хм, странно, вроде там ничего колом не вставало, просто академический интерес, спасибо )))

Значит оплачено ?

???

хм, странно, вроде там ничего колом не вставало, просто академический интерес, спасибо )))

mutex'ы работают везде одинаково

вызываешь Lock - смотрим взял ли уже кто-то лок, если не взял - меняем состояние, отдаем управление

если взял - ждем пока не отпустят

там могут быть тайматуы на ожидания, но суть та же

от платформы зависят детали имплементации

поэтому сделав: mutex1.Lock() mutex1.Lock() ты повесишь приложение

потому что вот

лок уже взяли, его никто не отпускал

точнее тредик повесишь

да я понимаю и в моем представлении также, просто действительных вставаний не было, шуршит в продакшине 24/7, поэтому было немного удивительно

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

попрофилируй мьютексы и увидишь

может быть

https://rakyll.org/mutexprofile/

да я уже уволился оттуда, нет доступа к коду и условий его выполнения )))

нууу

там могут и баги быть

и кто-нибудь где-нибудь мьютексы игнорирует просто напросто

увы частая проблема когда лок берется в одном месте, пишется в другом. Или пишется при взятом RLock'е

это да, согласен

попрофилируй мьютексы и увидишь

Достаточно заглянуть, что делается между lock и unlock мутекса ))

Имеет ли смысл использовать REST подход в обычном приложении используя js ?

Имеет ли смысл использовать REST подход в обычном приложении используя js ?

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

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

разверни. не понимаю, почему тебя должны PUT/DELETE беспокоить, тем более на hello world

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

Я просто смещаюсь в сторону вебдева, а именно в сторону vuejs(js) и столкнулся с тем, что в HTTP формах используется только GET и POST , что несколько меня обескуражило ибо сама философия REST мне очень понравилась ибо для каждого метода своё действие, а городить /post/delete/{ID} и /post/add/{ID} ну как-то не очень ... (

Я просто смещаюсь в сторону вебдева, а именно в сторону vuejs(js) и столкнулся с тем, что в HTTP формах используется только GET и POST , что несколько меня обескуражило ибо сама философия REST мне очень понравилась ибо для каждого метода своё действие, а городить /post/delete/{ID} и /post/add/{ID} ну как-то не очень ... (

rest api - это не про формы. это про клиенты.

подписываешься на onSubmit, асинхронно дергаешь метод апи любым http методом

ограничений нет

REST конечно хорош, но в больших проектах могут возникнуть сложности. Особенно с кастомными экшенами вроде поиска, фильтров, форм с мультисущьностями. Которые не очень то укладываются в концепцию. Если вам только CRUDL нужен, тогда юзайте REST. Мы изначально выбрали его, но потом он мутировал что-то иное что сложно назвать RESTом

подписываешься на onSubmit, асинхронно дергаешь метод апи любым http методом

понял, спасибо. В любом случае прийдёться дергать определённые скрипты .

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

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

посмотри в файлах чата - там есть и по вебу

в контексте го

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

shtein.ddns.net:8080

shtein.ddns.net:8080

че ты все спамишь своим сайтом?

че ты все спамишь своим сайтом?

хвастаюсь(

за такое можно и бан схлопотать

баньте к херам! тем более что сайт перестал работать

Ты наверняка себе DDos организовал, скинув сюда ссылку. Все начали заходить на сайт, делиться ссылкой с друзьями... Так сайт и лег

Хабраэффект

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

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

но без кеша по-моему сейчас никто не делает

Без кэша вряд ли бы тоже лег)

Странное утверждение насчёт кеша

Странное утверждение насчёт кеша

?

Без него вполне можно

а смысл ?

се

Базы неплохо кешируют если мощности позволяют

Зачем городить лишний слой?

Базы неплохо кешируют если мощности позволяют

какие базы ?

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

))

то есть коннекты к базе ничего не стоят теперь ?

До определённых масштабов об этом можно не беспокоится

А ЧТО ТЫ ЗА КАЖДЫЙ КОННЕКТ ПЛАТИШЬ?! ТЕБЯ ОБМАНУЛИ ЕСТЬ БЕСПЛАТНЫЕ БАЗЫ

nginx cache, varnish, memcached...redis и пр. это лишний слой ?

До определённых масштабов об этом можно не беспокоится

tsya.ru

Да, если работает без них

А ЧТО ТЫ ЗА КАЖДЫЙ КОННЕКТ ПЛАТИШЬ?! ТЕБЯ ОБМАНУЛИ ЕСТЬ БЕСПЛАТНЫЕ БАЗЫ

временем

ты всю шутку испортил серьезно на нее ответив(

tsya.ru

?

в общем мое личное мнение, на проекты такого рода (сборник статей) можно повесить nginx cache over memcached с соединением по сокету, самый быстрый способ сделать сайт более-менее непробиваемым

Если сайт это бложек с 200 униками в сутки можно вообще не заморачиваться

Учитывая что PostgreSQL/MySQL вполне себе на "среднем" железе выдают десятки тысяч запросов в секунду, прикручивание "с боку" всех этих кэшей зачастую избыточно и несет с собой кучу проблем. Тоже касаемо Редиса, часто реляционки гораздо более шустрые, если есть развесистая логика и ее можно положить в СУБД, чем несколько раз сбегать в Редис и пытаться что-то сделать на стороне приложения

то есть коннекты к базе ничего не стоят теперь ?

Ну, гошный драйвер достаточно неплохо "пулит" конекты, часто открывать не надо, да и много тоже

Учитывая что PostgreSQL/MySQL вполне себе на "среднем" железе выдают десятки тысяч запросов в секунду, прикручивание "с боку" всех этих кэшей зачастую избыточно и несет с собой кучу проблем. Тоже касаемо Редиса, часто реляционки гораздо более шустрые, если есть развесистая логика и ее можно положить в СУБД, чем несколько раз сбегать в Редис и пытаться что-то сделать на стороне приложения

пример который я описал выше будет работать быстрее в любом случае. В 90% случаев там даже дела до приложения не дойдет nginx -> кеш из оперативки и обратно

Тогда лучше просто статический ХТМЛ нагенерить

все-равно из memcached будет быстрее

быстрее чего ?

статических файлов

я же пишу про связку с nginx

nginx может и в статику кешировать

но c memcached это быстрее

суть в том что в memcached будет лежать тот же html но только не на диске а в оперативке