[過去ログ] Go language part 3 (1002レス)
前次1-
抽出解除 レス栞

このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
82: デフォルトの名無しさん [sage] 2019/11/19(火) 19:41:52.54 ID:nsf/4FCJ(1) AAS
ごーでぶキュレーションサイトなのかな
外部リンク:japan.zdnet.com
510: デフォルトの名無しさん [sage] 2020/05/16(土) 15:30:06.54 ID:9I4cSVvN(2/4) AAS
「この中にformがいっぱい入ってますよ」っていうformなんだよね
540
(1): デフォルトの名無しさん [sage] 2020/05/17(日) 08:16:05.54 ID:Y3GCZn29(3/9) AAS
>>535
535(2): デフォルトの名無しさん [sage] 2020/05/17(日) 07:48:39.85 ID:8deP89zB(2/10) AAS
>>533
あなたの最終的な実装を元にして実装するならこんな感じかな(勝ってに拡張しちゃってるけど)
func (i *rInst) ParseForm() error {
var err error
r := i.request
ct := r.Header.Get("Content-Type")
ct, _, err = mime.ParseMediaType(ct)
if err == nil {
switch ct {
case "multipart/form-data":
if r.Method == "POST" {
err = r.ParseMultipartForm(100 * 1024)
} else {
err = errors.New(“invalid request”)
}
case “application/json”:
d := json.NewDecoder(r.Body)
// i.Json = make(map[string]interface{})
i.Json = &BindStructure{}
err = d.Decode(&i.Json)
default:
err = r.ParseForm()
}
}
return err
}

まぁ、頑張って。
あ、REST-APIでよく使われる形式なのか
そういうForm使わない呼び出しはサポートしないんで割愛

POST以外のAPIアクセスは事前に拒絶してるから割愛

現状でも問題ないな(手抜き)
623
(1): デフォルトの名無しさん [sage] 2020/06/01(月) 08:54:16.54 ID:glX8U9VC(1/2) AAS
MSはaspnetcoreのベンチマークにTechEmpowerを使ってることを公言してるんで眉唾
オーバーフィッティングの可能性がある
727: デフォルトの名無しさん [sage] 2020/09/30(水) 05:11:09.54 ID:/dbaz1tV(1) AAS
Elixir は、10万の小プロセスが、並列で動く

結局、Rust, Elixir は、普及のキャズムを越えられなかったから、
Go の1強になってしまったけど
733: デフォルトの名無しさん [sage] 2020/09/30(水) 20:05:41.54 ID:HXdd4xfV(1) AAS
ゴリゴリ書かなきゃいけないという点で面倒くさいけどゴリゴリ書いてしまえるという点で面倒くさくない
816
(2): デフォルトの名無しさん [sage] 2020/11/01(日) 20:36:44.54 ID:Cb/zzig7(1/4) AAS
>>814
814(1): デフォルトの名無しさん [sage] 2020/11/01(日) 18:37:50.76 ID:0aiHjqpe(9/12) AAS
>>810
> M:Nで、かつスケジューラがまともな場合、に関しては相当美味しいと言う事が理解できて
俺は別に美味しいとは思ってないぞ。
M:NならOSのスケジューラと大差ない筈だし、
実際ランタイム判断でN:1に出来る状態でもNodeに負けてるだろ。
カッコイイスケジュールをやりきるより、スケジュールなんてしない、の方がシンプルで速いんだよ。
Goは例の「一方ロシアは鉛筆を使った」のアメリカ側をやりきってる感じがある。
とはいえそれもソフトウェア全体の成長の芽の一つだから、やること自体は頑張れ、でしかないが。

> スケジューラのソースはgithubにあるはずだが、読んだ?
読んでねえよ。ただ、読む価値ねえから読まねえよ。遅いスケジューラなんて意味ねえし。

> Netの話はネイティブスレッド
つまり普通のスレッドだろ?ならWindowsはスレッドのスタックサイズを指摘出来ることになる。
Linuxでこれが出来ないとも思えないので、goroutineは軽いんです、なんて利点はなくなると思うが。

>>812
そりゃお前が理解出来てないと思うぞ。
上述の通り、スライドでもメッセージをkernelに投げてるだろ。
そこを同一CPU内にディスパッチされた場合にのみN:1専用超軽量ルーチンで処理するよう、
スレッドスイッチの際に全部張り直す、というのもありだが、実際それやってても大して速くないと思うぞ。

そこは本来はプログラミングモデルを明示的に変えないと駄目なんだよ。
同一CPU内でのみ動作するスレッドであれば、スイッチのコストはほぼゼロだから、がんがん切り出して問題ない。
一方、メッセージにkernelを挟む必要があるのなら、それはそれだけでコストがかかるから、何でもかんでも切り出したら余計遅くなる。
だから本来は goroutine のみではなく、 golight とか、N:1スケジュール専用のgoroutineを用意しないと駄目なんだ。
それがなくて全部goroutineで扱うから全体的に遅くなってしまう。それがブログ主がやった事だよ。
ただこれを分離するのは思想的にやりたくないんだろ?ならそこが限界だよ。
スケジュールなんかしない、って全然ありえないんじゃないか?それこそ非同期の時代に。
Nodeにはだいたい勝ってるかと。

読んでもないのに読む価値がわかるとは凄いな。

スレッドのスタックサイズが問題ではなくて、ネイティブスレッドか否かが問題なの。アホか?

だから、スレッドではないから、スイッチのコストが全然違うの。
goroutineはスレッドのようなものであって、スレッドではないからそもそも切り替えのコストがほぼない。
だからガンガン切り出していいの。
なんにも聞いてないのな。グリーンスレッド勉強になったんじゃないの?
964
(3): デフォルトの名無しさん [sage] 2020/11/13(金) 23:02:04.54 ID:5mXtPG+h(2/2) AAS
>>963
963(1): デフォルトの名無しさん [sage] 2020/11/13(金) 22:59:31.91 ID:YBOwt/E7(1) AAS
>>960
wikipediaの解説くらい読めよ……

イテレータ(英語: iterator)とは、プログラミング言語において配列やそれに類似する集合的データ構造(コレクションあるいはコンテナ)の各要素に対する繰り返し処理の抽象化である。

「連続した要素」である必要は無いし、「一個ずつ舐め」る必要も「処理する」必要も無いぞ。
えっ、繰り返し処理って一個ずつ舐める以外の手法ある?
実際なにかするかは別として、絶対舐めるよね?
993: デフォルトの名無しさん [sage] 2020/11/15(日) 23:02:20.54 ID:oqZpf0kM(2/2) AAS
Go案件はメルカリ一派しかまともにやってないから
その周辺の会社に行け
給料もクソ高い
前次1-
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル

ぬこの手 ぬこTOP 0.040s