フィールドを保護してるだけだったら大丈夫なんですけど

9:04 AM

「syncで状態を読める」価値をちゃんと出そうとすると

9:05 AM

「状態を変更するメソッド」も、syncで呼べるようにしないとあんまり意味がない状況が出てくるんですよね

9:05 AM

でも、状態を変更するメソッドの中でロックしている内部で更に別のメソッドを呼ぶとか

9:05 AM

ロックしている内部のタイミングでコールバックしたいとか

9:06 AM

そういう要求が出てきたときにデッドロックのリスクが浮上してくるって感じです

9:06 AM

デッドロックを避けようとするとその部分だけは非同期で遅れてコールバックされる仕組みになるので

9:07 AM

設計上の線引が難しくなると言うか。

9:07 AM

reentrantなので難しいと言うか、actorはデッドロックしないアーキテクチャとしてreentrantを選択しているので

9:08 AM

内部でのロックを導入すると、actorによって心配する必要がなくなったデッドロックのことを

9:08 AM

また考えないといけなくなってくるのがデメリットって感じですかね

9:11 AM

iOS SDKで提供されてるいろんなモジュールは一般的には同期な操作と非同期な操作が混在しているので、そういうものを作りたい要求はあるはずで、Actorの中でロックを活用する、というのも間違っているわけではないです、ただ難しいという話です

9:12 AM

Actorの思想はそこから進んで同期的な操作を完全に捨てる次世代の設計思想な感もありますが、 UI描画更新とかでどうしても同期になっていてほしいものってありますからねえ。 (edited)