Ryo Kanbayashi ryogrid

Rustでの実システムを想定したシミュレータでは何のロックを取ればよいのか

リエントラントロックを使っている点には注意が必要
- 各API呼び出しで起動されるスレッドは呼び出しごとに別々である。したがって、別ノードを中継して同じノードのAPIを叩いた場合は、実システムに合わせるならば2回目のロック取得はブロックされなければならない
- ただし、同一ノード内ではAPI呼び出しという形はとれないはずなので、そういったケースでは同じスレッドが複数のAPIに対応する処理を行う場合もあるはずで、その際は同一のロックを複数回とれても問題ない　
ノードオブジェクト自体のロックを各オペレーション担当スレッドが持ち続ける必要はなく、持ち続けてはいけない
- 他のスレッドは、そのオブジェクトをラップしたArRmRs型のオブジェクトをglobal_datasから得ることができるが、ロックをとってラップをはがすことができなくなる　
現状、複数スレッドで触れるように排他できるのは、ChordNodeにArRmRs型のフィールドとして持たせている3つのクラス単位でしかないような気がする。。。しかし、それでいいような気もする。
★ただ、クリティカルセクション区間を設けようとした場合は別の仕組みの導入が必要なような★

Background

The NIP-36 specification requires that post be tagged with a content-warning tag (so that users can clearly identify the post as such when they post it). However, even if this is done, non-NIP-36 compliant clients still display tagged posts as usual.

As a result, although overall compliance with the specification is progressing, a non-negligible percentage of clients do not support NIP-36, leaving users with a psychological barrier that makes it difficult to post Sensitive Content.

Therefore, the purpose of the specification is to avoid users of non-NIP-36 compliant clients from unintentionally viewing content with content-warning tags, and to allow Nostr users to think that it is safe to post Sensitive Content if they specify content-warning tags.

The following service was developed to avoid unintentional viewing of content with content-warning tags and to make Nostr users feel it is safe to post sensitive content with specifing content-warning tag.

	最新のTODOコメント全て（21/05/03 19:51）
	/mnt/h/work/rust_kvs/chord_sim/modules% find . -name "*.py" \| xargs grep -n "TODO:" > /mnt/c/Users/ryo/Desktop/chord_sim_TODO_comments.sh
	./chord_sim.py:159: # TODO: 実システム化する際は、リトライ処理は各オペレーションに対応するRESTインタフェースの呼び出し
	./chord_sim.py:193: # TODO: handle stabilize_successor at do_stabilize_successor_th
	./chord_sim.py:388: # TODO: gval.all_data_list は検索のコストを考えると dict にした方がいいかも
	./chord_sim.py:482: # TODO: 対応する処理を行うスクリプトの類が必要 node_join_th
	./chord_sim.py:489: # # TODO: デバッグのために1000ノードに達したらjoinを止める。後で元に戻すこと!
	./chord_sim.py:502: # TODO: RESTでエンドポイントを叩くテストプログラムが必要 data_put_th
	./chord_sim.py:511: # TODO: RESTでエンドポイントを叩くテストプログラムが必要 data_get_th
	./chord_sim.py:524: # TODO: 適当に選んだプロセスをkillするスクリプトなりが必要 node_kill_th

	/mnt/h/work/rust_kvs_win_rust_env/chord_sim_rust/src% find . -name "*.rs" \| xargs grep -n "TODO:" \| grep rust \| ruby -pn
	e '$_ = sprintf("%-35s", $_.strip.split("//")[0]) + " # " + sprintf("%-50s", $_.strip.split("//")[1]) + "\n"' > /mnt/c/
	Users/ryo/Desktop/chord_sim_TODO_comments_rust.sh
	して出来たファイルをVS Codeで開いて Format Document して、あとズレてるところをちょこちょこいじる

	./chord_node.rs:601: # TODO: (rust) 実際にKVSとしてデータのput、getを行うようになったらこのフラグは
	./chord_util.rs:624: # TODO: (rust) 将来的にはNodeInfoのロックを保持し続けなくて済むように出力に必要な要素を各々引数に渡す形に
	./endpoints.rs:121: # TODO: (rust) ダミー実装なので委譲処理が必要になったタイミングで対応すること
	./main.rs:1169: # TODO: (rust) リトライ関連の処理は後回し
	./main.rs:1202: # TODO: (rust) ひとまずjoin処理が成功していようがいまいが all_node_dictに追加してしまう

	■SamehadaDBのTODO
	・【済】TransactionManager?のBeginとCommitを現在のexecutorのテストケースではどう暫定実装しているのか確認
	・【済】executor系のテストやloggingのテストでTransactionManagerのBeginとCommitが呼び出されるようにする
	・【済】TransactionManagerクラスとTransactionクラスの実装
	・【済】"// TODO(student): add logging here" と cpp実装でコメントされている箇所のif文をSamehadaDBのgoのコードベースにも加える
	・【済】logging/recoveryの実装
	-【済】C++実装版の非同期I/Oの仕組みをチェックしておく（別のBusTubフォークを参照する形かな）
	-【済】flush thread が logging に必須であるか確認し、必要なら対応する
	-【済】recovery_test のテストケースのセットアップをSamehadaInstanceを使う形にしたが、他のテストケースと比較して、
	必要な処理が行われているかを確認・対応

	./execution/plans/aggregation.go
	103: // TODO: (SDB) [OPT] not implemented yet (AggregationPlanNode::GetDebugStr)
	./execution/plans/delete.go
	36: // TODO: (SDB) [OPT] not implemented yet (DeletePlanNode::GetDebugStr)
	./execution/plans/insert.go
	56: // TODO: (SDB) [OPT] not implemented yet (InsertPlanNode::GetDebugStr)
	./execution/plans/limit.go
	46: // TODO: (SDB) [OPT] not implemented yet (LimitPlanNode::GetDebugStr)
	./execution/plans/orderby.go
	80: // TODO: (SDB) [OPT] not implemented yet (OrderbyPlanNode::GetDebugStr)

	NOTE: linux environment is WSL1 on Windows10

	ryo@DESKTOP-IOASPN6:/mnt/c/Data/work/go-bench$ uname -a
	Linux DESKTOP-IOASPN6 4.4.0-19041-Microsoft #1237-Microsoft Sat Sep 11 14:32:00 PST 2021 x86_64 x86_64 x86_64 GNU/Linux

	ryo@DESKTOP-IOASPN6:/mnt/c/Data/work/go-bench$ go version
	go version go1.20.7 linux/amd64

	ryo@DESKTOP-IOASPN6:/mnt/c/Data/work/go-bench$ gccgo --version
	gccgo (Ubuntu 10.5.0-1ubuntu1~20.04) 10.5.0

	NOTE: linux environment is WSL1 on Windows10

	# based benchmark code: n-body (added little modifications by ryo_grid for excecuting same logic)
	https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/nbody-gcc-3.html
	https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/nbody-go-3.html


	ryo@DESKTOP-IOASPN6:/mnt/c/Data/work/go-bench$ uname -a
	Linux DESKTOP-IOASPN6 4.4.0-19041-Microsoft #1237-Microsoft Sat Sep 11 14:32:00 PST 2021 x86_64 x86_64 x86_64 GNU/Linux

	=== RUN TestSimplePlanOptimization
	System logging is active.

	Pattern Name: Simple(SequentialScan)
	[ select Sc1.c1 from Sc1 where Sc1.c1 = 2; ]
	==================================================
	ProjectionPlanNode [sc1.c1, ]
	ProjectionPlanNode [sc1.c1, ]
	SelectionPlanNode [ colIndex:0 2 = ]
	SeqScanPlanNode [sc1.c1, sc1.c2, sc1.c3, ]