Rust part34

**デフォルトの名無しさん** · 2025/11/27(木) 12:25:23.76

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

公式ドキュメント
https://www.rust-lang.org/learn

Web上の実行環境
https://play.rust-lang.org

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※次スレは原則>>980が立てること

前スレ
Rust part33
https://mevius.5ch.net/test/read.cgi/tech/1755247770/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2025/12/11(木) 12:54:01.07

複オジだらけ

**デフォルトの名無しさん** · 2025/12/11(木) 12:58:56.52

自作自演

**デフォルトの名無しさん** · 2025/12/11(木) 18:48:54.72

>>124
返し値に利用可能なレジスタの範囲内ならレジスタ返しが速い
RVOはそのサイズを超えてから

**デフォルトの名無しさん** · 2025/12/11(木) 22:15:21.89

RVOとは違う話だけどC++は戻り値を std::move した方が良いケースは結構あるぞ
戻り値というか、戻り値の型に渡すコンストラクタに対して渡す時の話だけど
戻り値が std::string や std:: vector をフィールドに持つ構造体やタプルで、最後の return で初期化してるような場合

return { std::move(str); };

こういう場合は str は自動ではちゃんとムーブしてくれなかった気がする
(最近のC++は知らんから、間違ってたら指摘がほしい)

**デフォルトの名無しさん** · 2025/12/11(木) 22:42:19.12

みんな当たり前にC++を引き合いに出しているけど、Rust書いてる人でC++エアプ勢っていないんだろうか

**デフォルトの名無しさん** · 2025/12/11(木) 23:34:58.81

Cのみはいるかもしれないが、少なくともC系統の言語を触れてないと
Rustがこんなに苦労して解決しようとしてる問題への実感が持てなくて
GC言語やスクリプトよりちょっと速いだけの、冗長構文クソ言語以外に感想持てなそう

**デフォルトの名無しさん** · 2025/12/11(木) 23:46:18.77

>>121
何を誤解してると思ったの？

それとその定義だとconcurrency controlは常にmutual exclusionというpropertyを持ってるという関係になるけどCSの一般的定義ではそういう関係ではなくてconcurrency controlを実現する手段の一つとか実現手段の一部という関係

**デフォルトの名無しさん** · 2025/12/12(金) 00:36:09.89

横からだけど、引用文においてもミューテックスは並行プログラミングにおける安全性アプローチのひとつと定義してると思うが
両者共に「並行制御 ⊃ 排他制御」という認識ではないの？
何が論点になってんだ？

**デフォルトの名無しさん** · 2025/12/12(金) 01:29:09.26

>>132
ミューテックスが必要となるのは「並列」プログラミング
拡張ワーカーを使わない限り
JavaScriptは「並行」プログラミングかつシングルスレッドなのでミューテックスが不要

**デフォルトの名無しさん** · 2025/12/12(金) 02:06:45.48

>>128
最近のC++では間違い

std::move()を書かなくても自動でムーブしてくれるし、
わざわざstd::move()を書いたことでNRVOを妨害してしまう

**デフォルトの名無しさん** · 2025/12/12(金) 02:22:06.56

>>133
>JavaScriptは「並行」プログラミングかつシングルスレッドなのでミューテックスが不要

そこは JavaScript は並行プログラミング"でありながら"じゃね？
「ミューテックスの要否」は「シングルスレッドであること」で定まり、したがって「並行プログラミングであること」を接続詞"かつ"で「並行させる」のは説明として不適かと

そしてなんについて議論してんの？
おふたりが論点としているものがはたから見ていて判然とせん

**デフォルトの名無しさん** · 2025/12/12(金) 02:41:47.22

>>132が並列と並行の区別ができてないからでしょう

**デフォルトの名無しさん** · 2025/12/12(金) 03:11:39.93

>>136
それは具体的にどの部分からそう読み取ったの？

「シングルスレッドであること」によって、「ミューテックスの要否」は定まる
したがって並列か並行かとは別議論では？
そもそも本件において前者は考慮不要かと

**デフォルトの名無しさん** · 2025/12/12(金) 03:30:00.02

>>137
mutexは同じCPU内の話だから並列＝マルチスレッドでしょ
でも>>132は区別できてなくて並行プログラミングと書いてます
並行プログラミングでは値を同時に更新することがないためmutexは要らないです
並行並列プログラミングまたは並列プログラミングの時のみmutexが要ります

**デフォルトの名無しさん** · 2025/12/12(金) 06:22:33.05

>>138
>mutexは同じCPU内の話だから並列＝マルチスレッド

ミューテックスの要否は端的に言えば「共有リソースに対するアクセスの有無」
マルチスレッドは並列を実現するためのいち技術であり、限定するのはミスリード
マルチコア、マルチソケット（NUMAなど）もまたしかり
「同じCPU内」という単位は不正確

>でも>>132は区別できてなくて並行プログラミングと書いてます

「並行制御 ⊃ 排他制御」と同じこと
「並行 ⊃ 並列」で並行は抽象レベルの概念であり、並列は物理レベルの実現方法
前者が後者を含意するのでこれらの記述は極めて自然

>並行プログラミングでは値を同時に更新することがないためmutexは要らないです

したがってこれは明確に誤り
>>136 を熨斗付けてお返しいたします

>並行並列プログラミングまたは並列プログラミングの時のみmutexが要ります

同上
レイヤの違う概念、用語を並行させて書いてしまってる
重ねるけれど、ミューテックスの要否基準は「共有状態の同時アクセス可能性」のみ

とりあえず >>121 の引用部分がそもそも間違ってるという主張？
そうであるなら以下に対して反論どうぞ

>In computer science, mutual exclusion is a property of concurrency control, which is instituted for the purpose of preventing race conditions.

**デフォルトの名無しさん** · 2025/12/12(金) 06:46:29.30

>>139
あなたのような知識が足りなく偏った人を相手にするのは大変だけど
単に並列プログラミングといえば複数のPCを用いる分散型の並列プログラミングを含むのよ
話題の領域を明確にするために今回はmutexの話だから分散型の話題ではないと限定しているわけ
そういう常識を持たないかあえて無視して無意味に突くだけのダメ人間みたいだからこれ以上はくだらないやりとりしません

**デフォルトの名無しさん** · 2025/12/12(金) 08:00:06.77

>>140
>単に並列プログラミングといえば複数のPCを用いる分散型の並列プログラミングを含むのよ

いやあ、そんなことはないと思うが
少なくともこちらは本件において分散コンピューティングには触れていない

>今回はmutexの話だから分散型の話題ではないと限定しているわけ

心得てるけど
その上で「ミューテックスの要否」は「共有リソースに対する同時アクセスの有無」と言明しているわけであり

あなたが以下のようにミューテックスの用途を誤解、もしくはミスリードをしていたもので、反例をいくつか挙げてわざわざ説明したのであって（マルチコア、マルチCPU = マルチソケット｟同一マシン内のNUMAノード間｠）
マルチスレッドは並列の一形態でイコールではない
共有リソースへの同時アクセスが起こりうるなら、スレッド、コア、ソケットの別なく排他制御はごくごく自然な選択肢
ちなみにNUMAはわかる？複数PCの使用や分散技術の話じゃないよ

>mutexは同じCPU内の話だから並列＝マルチスレッドでしょ

そしてそもそも並列と並行の区別だが、これについてもレイヤが違うと説明したはず
「並行 ⊃ 並列」
並行はより上位の抽象概念だから、並行プログラミングに言及する際、ミューテックス（排他制御）を取り上げるのは当たり前

したがって以下は明確に誤ってるかと

>並行プログラミングでは値を同時に更新することがないためmutexは要らないです

並列だろうが並行だろうが、リソースへの競合状態が起こりえるなら、ミューテックスは要検討

**デフォルトの名無しさん** · 2025/12/12(金) 09:10:06.26

JavascriptのPromise chaining（シリアル実行）は排他制御に含まれると思う
前の処理がPendingの間は次の処理を実行しないから前の処理で更新中のデータが次の処理で参照されない

**デフォルトの名無しさん** · 2025/12/12(金) 10:18:13.52

>>139
間違い多すぎなので正解だけ書くと
並行処理＝同時進行するが同時に実行されることはない
並列処理＝同時に実行されるためメモリ競合などの対策が必要

**デフォルトの名無しさん** · 2025/12/12(金) 19:40:37.53

T型を[T;1]型にするのはゼロコストだよね

**デフォルトの名無しさん** · 2025/12/12(金) 21:31:17.66

>>143
>並行処理＝同時進行するが同時に実行されることはない
>並列処理＝同時に実行されるためメモリ競合などの対策が必要

教科書レベルのあるある理解（誤解）
既述したよう、並列処理は並行処理のいち手段
「並行」という概念の中に含まれる
それを物理レベルで「並列に処理」（同時実行）するか否かは別議論であり、レイヤが違う

並列でないなら競合しないの？
並列でないならマルチスレッド処理できない？

整理したいけど >>121 の引用部分に異議ある立場？

>In computer science, mutual exclusion is a property of concurrency control, which is instituted for the purpose of preventing race conditions.

「concurrent」をどう訳します？

**デフォルトの名無しさん** · 2025/12/12(金) 22:57:57.08

>>134
不安になって試してみたけど、このケースだと現代のC++コンパイラでも std::move が必要だぞ
>>128 の変数 str の部分を non-copyable なもの (例. std::unique_prt<T>) に変えると、std::move 無しだとコンパイルエラーになる
自作クラスで試しても、std::moveしないとコピーが作られる (外側の構造体そのものはRVO最適化が効くけど、その構造体に渡されるデータは左辺値参照で渡される)

**デフォルトの名無しさん** · 2025/12/12(金) 23:21:06.40

wikipediaを見る限り>>143の区別みたいよ

>並行計算は、並列計算（parallel computing）としばしば混同される。
>
>並列計算はマルチプロセッサ前提であり、独立した各プロセッサが割り振られた計算を同時実行することを指す。
>故にシングルプロセッサでは不可になる[2]。
>分散システム内の各コンピュータが割り振られた計算を同時実行するのもそうである。
>
>並行計算は一つのプロセッサに複数のタスクを存在させて、各タスクに計算を割り振ることを指す[4]。
>そこではタイムシェアリング技術などが使われる。

**デフォルトの名無しさん** · 2025/12/12(金) 23:23:20.57

>>132
AはBのproperty(特性/性質/属性)の一つという定義と
AはBを実現するアプローチの一つ定義は同じではないよ

これはどっちかが絶対的な正解という問題ではなくて
mutual exclusionをどういう意味範囲で使ってるかの問題

compare-and-swapのようなatomic operationでも
レイヤーを掘り下げればクリティカルセクションがあって
mutual exclusionというpropertyを持ってると考えるなら
wikipediaの定義でもおかしくはない
(一般的かどうかはさておき)

あと何を誤解してると思ったのかは書いてもらわないとわからん

**デフォルトの名無しさん** · 2025/12/12(金) 23:45:04.62

>>133
1. ミューテックスと排他制御(mutual exclusion)を区別しよう
ミューテックスは排他制御を実現する方法の一つで
locked/unlockedの状態を管理する変数だったり構造体だったりの実装のこと
排他制御(mutual exclusion)という概念とは別もの

2. ワーカーを使わないシングルスレッドのJavaScriptにおいて排他制御は不要か？
もちろん必要
https://web.mit.edu/6.102/www/sp25/classes/16-mutual-exclusion/

3. ワーカーを使わないシングルスレッドのJavaScriptにおいてミューテックスは不要か？
ミューテックスが必要な状況ももちろんある
例えば複数のダウンロードリクエストを並行処理しているダウンローダーで
特定のサイトは最大1コネクションのダウンロードしか許可しておらず
複数同時ダウンロードをすると全部強制終了されてしまう状況とか

**デフォルトの名無しさん** · 2025/12/12(金) 23:59:32.76

>>149
無知だな
基本を分かっていない

ミューテックスはマルチスレッド時に同時アクセスの競合が起きる可能性がある場合に用いてスレッドを待たせる機能がある

特定のサイトは最大1コネクションのダウンロードしか許可してない場合
ワーカーを用いないJavaScriptは並行処理なのでミューテックスは不要
単なるカウンター変数のみでよい

**デフォルトの名無しさん** · 2025/12/13(土) 00:03:09.62

>>143
>並行処理＝同時進行するが同時に実行されることはない
>並列処理＝同時に実行されるためメモリ競合などの対策が必要
一般的な定義からすると↑これはどっちも間違ってる
並行処理は同時実行されてる部分もあれば同時実行できない部分ももある
同時実行できない部分の制御のため競合対策が必要

並列処理は同時実行可能な処理を指すので競合対策は不要
同時実行できない処理を並列処理とは普通は言わない

**デフォルトの名無しさん** · 2025/12/13(土) 00:07:42.28

>>151
wikipediaの記述やそこで引用している参考文献が正しい
あなたが間違っています

**デフォルトの名無しさん** · 2025/12/13(土) 00:07:52.21

>>150
>単なるカウンター変数のみでよい
それはカウンター変数をミューテックスとして利用しているってことなんだよ
>>149をもう1回読んでね

**デフォルトの名無しさん** · 2025/12/13(土) 00:36:34.04

現実的には単なるカウンター変数をミューテックスとして利用するだけではダウンローダーに必要な機能を満たせないからキューイングできるタイプの非同期ミューテックスを使う

**デフォルトの名無しさん** · 2025/12/13(土) 01:22:57.78

>>153
いいえカウンター変数とmutexは異なります
mutexは他のスレッドがロック中にスレッドを待たされる機能と利用が可能になったときに再開させる機能を伴います
その効率のためOSが提供するfutex機能を用いてmutexを実装する環境が多いです

**デフォルトの名無しさん** · 2025/12/13(土) 03:20:12.64

>>147
参照された記事には並行処理における競合対策は不要と記載されていました？

また、「コンピューティング」という、物理、実装を意識するレベルでの具体的差異をこちらは否定していない
その前段となる概念レベルの関係についての言及であり

>Concurrency is a broader concept that encompasses several related ideas, including:
>Parallelism (simultaneous execution on multiple processing units). Parallelism executes tasks independently on multiple CPU cores. Concurrency allows for multiple threads of control at the program level, which can use parallelism or time-slicing to perform these tasks. Programs may exhibit parallelism only, concurrency only, both parallelism and concurrency, neither.
https://en.wikipedia.org/wiki/Concurrency_%28computer_science%29#Related_concepts

実際に並行、並列処理の実装にあたっては、物理、ハードウェア的な制約に基づき、当然、両者は弁別される
言うまでもないがシングルコアにて並列処理は実装できまい
さりとて逆もしかりとならないわけで
前者は後者を包含している、後者は前者の下位概念であり、具体的な実現手段
「並行 ⊃ 並行、並列」のように概念のポケットに、それとは別に具体的技術としての「並行」「並列」が入るイメージ

そして繰り返すけど、本件論点は競合考慮、ミューテックスの要否では？
並行プログラミングする際、これを不要とする立場？

**デフォルトの名無しさん** · 2025/12/13(土) 07:39:32.48

>>156
並列を用いない場合＝マルチスレッドを用いない場合＝シングルスレッドの場合、
並行処理でメモリアクセスが同時に実行されることはないためメモリ競合は発生しない。
つまりカウンターやフラグなどあらゆる変数についてMutexを用いる必要がない。

これはJavaScriptだけでなくRustでシングルスレッドで非同期タスクを並行処理する場合も同じ。
具体的にはtokioのspawn (並行＆並列)はSendトレイト境界があるため変数共有にMutexなどが必須だが、
spawn_local (並行のみ)はSendトレイト境界がないためMutexは不要という形で表れる。

**デフォルトの名無しさん** · 2025/12/13(土) 08:07:26.77

関連型ってT<U>みたいな型依存型ができないからその代用だよね

**デフォルトの名無しさん** · 2025/12/13(土) 10:56:12.72

シングルスレッドでも２つの非同期処理がawaitを挟んで同じメモリを参照・更新する時は
data raceのリスクがあるから気をつけてくれ
Rustの場合は&mutが他の参照をブロックするから問題になりにくいけど

**デフォルトの名無しさん** · 2025/12/13(土) 11:00:34.93

日本語より
concurrent
parallel
distributed
で議論した方が良いと思うの
https://zenn.dev/koron/articles/3ddcaaeae37f9befdf70

**デフォルトの名無しさん** · 2025/12/13(土) 11:37:19.65

並行はヘテロ
並列はホモ

**デフォルトの名無しさん** · 2025/12/13(土) 12:58:20.04

同時アクセスの可能性があるものにmutexでロックかけろってだけじゃないの

**デフォルトの名無しさん** · 2025/12/13(土) 14:26:19.82

>>162
原則としてはそう。
ただ、データ競合は阻止できてもデッドロックは阻止できないし、性能的に改善できる余地もあるから唯一の正解というわけではない。

**デフォルトの名無しさん** · 2025/12/13(土) 14:26:52.20

>>162
Mutexは別々のスレッド同士が同時アクセスするデータ競合を防げるよ
通常のstd::sys::Mutexだと既にロックを持っている同じスレッドでロックしようとすると動作の保証はなくてパニックするかデッドロックするかなど環境依存なので用いてはダメだけど
つまりそれはマルチスレッド用

**デフォルトの名無しさん** · 2025/12/13(土) 14:48:01.82

一般的なアプリケーションプログラミングにおいては、排他制御の対象はデータというよりコードの特定のセクションであることが多い
当該セクションで扱うのが単一のデータストアである場合はそのデータストアに対する単純なロックに帰着するが、実際にはそうでない場合も多い

**デフォルトの名無しさん** · 2025/12/13(土) 15:10:49.43

ケントンプソンに書き直してもらったほうがいいだろこの言語

**デフォルトの名無しさん** · 2025/12/13(土) 20:30:59.61

自演するにしても、逆に自演ってバレバレになる1レスごとルーパチじゃなく
せめてWi-Fiとスマホ回線でやればいいのに

**デフォルトの名無しさん** · 2025/12/14(日) 00:57:37.50

>>157
まず初手の等式がぶっ飛んでいる
並行、並列という処理の性質とその処理を実際に行う際に用いるモデルの話は直交概念、因果の幅跳び甚だしい
「並列でない」ことによって、ただちに「マルチスレッドでない = シングルスレッドである」ことは定まらないため、「シングルスレッドで共有メモリを同時に操作可能な実行主体が一つしか存在しない」ことは担保しえない
ミューテックスの要否は「共有メモリに対して複数の実行単位が論理的に同時アクセスしうるかどうか」で、「物理的に同時実行されない」ことは必ずしもメモリ安全性を意味しない
すなわちコア数（並列か否か）とマルチスレッドのいかんは別議論
並行処理の実現手段としてマルチスレッドを用いたならば、メモリ競合は生じるし、したがってミューテックスも要検討
重ねるけれど「シングルスレッドである」とする際に、それを前提するのが「並行処理である」からというのは因果の車がパンクしている

**デフォルトの名無しさん** · 2025/12/14(日) 06:59:12.58

>>168
Rustでは>>157のように実装されているのだから君が間違ってるよ

**デフォルトの名無しさん** · 2025/12/14(日) 07:46:26.10

>>169
具体的に何が >>157 のように実装されているという話？
こちらの間違っている点はどこ？

**デフォルトの名無しさん** · 2025/12/14(日) 08:13:24.71

>>170
明確に>>157に書かれているのに理解できないならRustを使ったことすらないんのかな
長文で屁理屈を連投するけどRustの話が全く出てこないので怪しいと思っていたけど

**デフォルトの名無しさん** · 2025/12/14(日) 09:19:18.51

>>171
明確に前半後半で議論が分裂しているね
そして >>168 の指摘は前半の並行、並列、スレッド、競合、ミューテックスなどへの胡乱な認識に基づく主張、説明に対するもので、後半にて言及されてる「シングルスレッド」などに見られる条件下を前提としたケースについては触れていない

前半部分の指摘については既述のとおり
後半については指摘というより、並行、マルチスレッドなどの話で「Rustの話が出てこない」という反論かます時点で概念理解は推して知るべし

おそらく経験した個別ケースを安易に一般化してしまっており、自身の使っている用語が概念、実装、結果のどこに属しているか意識もあまりしていないのでは
だから乱暴な等式を使い、平気で一般化してしまう
Rust（tokioのexecutor）に見られる「設計上の制約（単一スレッドであることを保証）」は、「並行処理」一般とは議論のレイヤがズレている

そちらの議論に合わせるとすれば、spawn_localがmutex不要なのはexecutorが単一スレッドであることをtokioが保証しているからであり、「並行処理だから」が理由ではない

**デフォルトの名無しさん** · 2025/12/14(日) 09:48:55.96

>>172
非同期タスクで並行処理するためのランタイム基盤がRustのtokio
tokioでも並列処理をしない限り並行処理だけならばメモリ競合は発生しない
そのためミューテックスも当然必要ない
これは言語やランタイム基盤の種類に関係なく常に成立する

**デフォルトの名無しさん** · 2025/12/14(日) 10:39:55.53

相変わらず複数データの排他制御を理解していない複おじ

**デフォルトの名無しさん** · 2025/12/14(日) 10:52:14.74

>>173
mutexは必要がないだけでなく使用禁止が正解だよ
同じOSスレッド同士でmutexは機能しない

**デフォルトの名無しさん** · 2025/12/14(日) 11:11:39.26

複数データの排他制御ってなんの話？

**デフォルトの名無しさん** · 2025/12/14(日) 13:10:49.83

LinuxついにRust公用語に

**デフォルトの名無しさん** · 2025/12/14(日) 14:04:43.97

>>173
だから安易な一般化
「並行処理 = 非同期処理」と認識してない？
そちらの主張はtokioをはじめ、その中においての業界標準、常識であって、外に出たら通用しない
「並行処理」におけるメモリ競合の有無やミューテックスの要否じゃなくて、それを実現する実装手段の内側世界における議論

それらを前提してるから、「並行処理 = シングルスレッド = 競合しない = ミューテックスは必要ない」と因果を逆立ちさせてしまう
>>157 のレスを引くなら「並行（非並列） = シングルスレッド = spawn_local = Sendがない」ではなく、「spawn_localを選ぶ = tokioがシングルスレッドであることを保証 = スレッド移動がないためSend不要 = 結果として並行（非並列）になる」が正しい因果

設計段階で「並列か否か」をまず決めて、それに応じたexecutorを選択し、その結果、実装者の期待どおりに「並行（非並列）」or「並列 & 並行」となるわけで
これが本来の思考、理解の順序であって、逆にするから概念自体が胡乱げになる

「非同期処理」に限るのであればいざ知らず、そうでないなら、つまり「並行処理」一般に議論のスコープを広げるのなら、そちらの因果理解は破綻する

**デフォルトの名無しさん** · 2025/12/14(日) 15:01:36.46

>>178
長文くん邪魔だからさ
これ以上中身のない妄想の机上の空論を続けるのではなく、
キミが言う並行処理を実装してるクレートか何かをまずは持ってきなよ

**デフォルトの名無しさん** · 2025/12/14(日) 16:05:54.67

もう並行処理専用スレを作って移動してほしい

**デフォルトの名無しさん** · 2025/12/14(日) 18:14:00.68

長文は読んでないが>>157の複おじの主張に沿うと
実行環境がシングルコアならマルチスレッドでもマルチプロセスでも真の並列ではないから
「カウンターやフラグなどあらゆる変数についてMutexを用いる必要がない」ってことだな

あほらし

**デフォルトの名無しさん** · 2025/12/14(日) 18:21:41.85

今回得られた結論は以下の2つ

1. 「JavaScriptはシングルスレッドだから排他制御は要らない」などと言う人は排他制御を全く理解していないということ

2. 概念と実装の区別ができない人はその概念に対する理解が決定的に欠如しているということ

複オジ先生、反面教師役お疲れ様でした。

**デフォルトの名無しさん** · 2025/12/14(日) 18:51:23.07

複おじは日下部陽一先生と知りあえば仲良くなれると思う

**デフォルトの名無しさん** · 2025/12/14(日) 19:19:56.69

>>181
>>182
あなたは勘違いしてるから解説書や仕様書などまずは基本を勉強した方がいい
ミューテックスはスレッド間もしくはプロセス間で使われると明記されている
そして同一スレッド内でミューテックスを用いた場合の動作はは環境依存になる

Rustの標準ライブラリのMutexでも同様でロックされている状況にて同一スレッドでロックを試みた時の動作は指定されず関数から戻ってこないままpanicやdeadlockなどになりうると明記されている
つまりMutexはシングルスレッド内で用いてはいけないものなのだ

**デフォルトの名無しさん** · 2025/12/14(日) 21:37:57.47

シングルスレッドだからメモリ競合は発生しないって主張が地雷なんだよな

複数の非同期処理で共有してる&Cell<T>の値はawaitの前後で書き換わってる可能性があって
await中の別処理での変更を無視するとマルチスレッドのメモリ競合と同じ不定状態になる
この場合シングルスレッドだからMutexは必要ないというより使えないんだけど
Mutexが必要ないor使えないからメモリ競合は存在しないって結論出すのはやめてほしい

変なタイミングでawaitを挟まなければ回避できる話だから大した問題ではないけど
問題の可能性を理解せずに「メモリ競合は存在しない」って信念を持たれるとこわい

**デフォルトの名無しさん** · 2025/12/14(日) 22:10:35.13

>>185
それはメモリ競合とは言わない
そこにメモリ競合は存在しない

**デフォルトの名無しさん** · 2025/12/14(日) 22:37:59.93

まーた副クン一人で頑張ってるの？
IDコロコロして頑張るねえ

**デフォルトの名無しさん** · 2025/12/14(日) 22:56:57.21

複数CPUからの同時アクセスを制限するものだけを Mutex と呼ぶなら
tokio::sync::Mutex についてはどうなんだ？
これはシングルスレッドのランタイムでも使われるものだし、名前の通り Mutex と呼ばれるものの一種だと思うけど

**デフォルトの名無しさん** · 2025/12/14(日) 23:39:46.59

>>185
>変なタイミングでawaitを挟まなければ回避できる
OSが複数スレッドの実行をインターリーブするのと同じで
タスクも効率や公平性のためにawaitを入れてインターリーブさせるべきケースというのがある
>>149のダウンローダーの例とかね

**デフォルトの名無しさん** · 2025/12/14(日) 23:49:39.40

メモリ競合・データ競合は複数のスレッドもしくは複数のプロセスが互いにどこを実行している知らなくて制御できなかったり不意打ちで切り替わりえる状況で起きるんだよ

>>185
一方でそのケースはシングルスレッドで利用していればそんなことは起きないためデータ競合ではないね
awaitから戻ってきたら値が書き換わっていたというのは関数呼び出しの連鎖から戻ってきたら値が書き換わっていたのと同じようなこと
制御できない知らぬ間に値が書き換わるわけではないためデータ競合とは呼ばれない

**デフォルトの名無しさん** · 2025/12/15(月) 10:37:47.15

競合の話となると特に造語が捗るようですねえ

メモリ競合もそうだけど
データ参照の競合って何だったの？
https://mevius.5ch.net/test/read.cgi/tech/1722354386/966-983

**デフォルトの名無しさん** · 2025/12/16(火) 00:58:10.28

さてと
linuxカーネルはrust化されないとか言ってた低学歴在日朝鮮人の恥ずかしい書き込みを発掘するか

**デフォルトの名無しさん** · 2025/12/16(火) 01:13:24.49

Linuxって使いにくい　古～いUnixを未だにひきずってるから
Linuxに拘る必要あるんだろうか？
もういっそのことすべてを新規設計にしてLinuxに代わるオープンソースOSにして欲しい
モデルにするのは…MSはMSで変に使いにくくしていってるとこあるから、この両者の悪所を全部取り除いたやつにして欲しい

**デフォルトの名無しさん** · 2025/12/16(火) 01:14:30.50

複おじみっともないからそういうのやめなって

**デフォルトの名無しさん** · 2025/12/16(火) 01:23:26.93

排他制御で恥を晒した某オジさんがいつものように別のネタで話題をそらしたいわけですね

**デフォルトの名無しさん** · 2025/12/16(火) 01:36:51.09

Rustがこんなにも多くのアーキテクチャを葬ってしまうのか

https://x.com/ebisan2015/status/1999437822798045373

**デフォルトの名無しさん** · 2025/12/16(火) 03:40:58.95

unix作者はgo作ったしlinuxメンテナに入れて上げたらinじゃねーの？

**デフォルトの名無しさん** · 2025/12/16(火) 04:03:56.34

>>196
s390とホビーじゃねえぞ

**デフォルトの名無しさん** · 2025/12/16(火) 16:45:22.50

Qiitaスレに逃げてんじゃねーよ

**デフォルトの名無しさん** · 2025/12/16(火) 19:10:40.61

>>193
firefoxすらRustで書き直せないのに無理
ていうか、Rustはｵﾜｺﾝ

**デフォルトの名無しさん** · 2025/12/16(火) 19:45:33.35

Go のランタイムがやってる平行処理 (goroutine) は本当は OS でやりたかったが Linux にかわる OS を作るのは非現実的だから諦めたとは聞いたことがあるな。
単純な話としてアプリケーションが Linux の仕様に依存しきっているから Linux のしがらみを捨てた新しい OS を作ったら全てのアプリケーションが作り直しだ。
インフラは正しくあることよりも安定していることが重要であるという Linux 哲学により、改善によって既存のアプリケーションが動かなくなるならその改善はしないことになっている。(深刻な脆弱性ならやむを得ず修正することはある。)
つまり Linux は長期的に安定してバイナリ互換性を維持していて、更にはこれからもそうであると信じられているから今の地位にあるってことだ。 Windows もそう。
機能・性能の良さより長期的な信頼が大事で、それを得るのは本当に困難な話。

**デフォルトの名無しさん** · 2025/12/16(火) 20:04:03.07

新しいOSに引継ぎのためのWSLのようなのを積んじゃえば

**デフォルトの名無しさん** · 2025/12/16(火) 20:08:57.42

BeOSやTRONのようなのでもよかったんだけどなあ
BeOSはなぜかすぐに消えちゃったね、TRONはお国の事情で…

**デフォルトの名無しさん** · 2025/12/16(火) 20:25:59.95

>>201
goroutineはプリエンプティブつまり強制中断スケジューリングなので個別にスタックを持たなければいけないけど
Rustの非同期タスクはawaitでスケジューリング切替なのでyield_now等で自分で制御できるメリットとスタックを持たなくていいメリットがあるね

**デフォルトの名無しさん** · 2025/12/16(火) 20:51:19.88

おじはなんで188だけガン無視なの

**デフォルトの名無しさん** · 2025/12/16(火) 21:55:03.07

もう敗北を認めてるからでしょ

**デフォルトの名無しさん** · 2025/12/16(火) 22:02:24.31

Rustに勝つのは無理すぎる

**デフォルトの名無しさん** · 2025/12/17(水) 00:04:52.78

せっかくノリノリで自演再開したのに蒸し返された途端に止まるの笑える

**デフォルトの名無しさん** · 2025/12/17(水) 00:05:33.31

どういう指標において？
例えば「開発者の人口の多さ」なら主要言語の中では下位だし、そんなもの切り口によりけりだろ

**デフォルトの名無しさん** · 2025/12/17(水) 00:37:34.86

tronはスウィッチ2のコントローラで活躍しとるでぇ🧐

**デフォルトの名無しさん** · 2025/12/17(水) 09:00:54.55

活躍ではないかな

**デフォルトの名無しさん** · 2025/12/17(水) 13:00:34.90

NeXTは死にかけのところをあやうく拾って貰えた
BeOSの方がmac後継の有力候補とまで言われていたのに
ここまで立場がひっくり返るとは

**デフォルトの名無しさん** · 2025/12/17(水) 13:20:26.44

マイナーアーキテクチャ対応はgccrsプロジェクトの成否にかかってると思うんだが
現状どうなってるの？

**デフォルトの名無しさん** · 2025/12/17(水) 14:23:26.87

そんなもんお荷物になるだけだから失敗してくれた方がいい
最新エディションへの対応が遅れる(or放棄される)のは目に見えていて、
ライブラリがそれに引きずられて最新エディションへの移行を渋るようになれば、
俺達イケイケ最先端ウェーイでやってきたRustコミュニティの自尊心に致命的なダメージを与え、開発者離れを引き起こすことになりかねない

**デフォルトの名無しさん** · 2025/12/17(水) 16:13:18.06

アーキテクチャのLLVM対応はベンダーorメーカーの責任では
売りたいなら真っ先に用意するだろうし時代遅れでコストに見合わなければ切り捨てられる

**デフォルトの名無しさん** · 2025/12/17(水) 19:33:27.44

というかgcc対応の本命はrustc_codegen_gccの方じゃない？
最近はRust本体のCIでもテストされるようになってきたし、rustupでの配布も計画されている

**デフォルトの名無しさん** · 2025/12/17(水) 20:42:52.22

>>216
rustc_codegen_gccはrustcのバックエンドとしてLLVMと同様の立ち位置なんだよね
だから>>214の問題は起きないメリットが大きい

**デフォルトの名無しさん** · 2025/12/17(水) 22:06:20.53

bincode がサポート終了になったみたい
それなりに広く使われてるクレートでも突如消えることってあるんだな、と改めて思う…

**デフォルトの名無しさん** · 2025/12/17(水) 22:27:57.16

メンテナの一人が他のメンテナに相談なく脱GitHub作業を始めて履歴の書き換えとかをやりだして揉めたけど
その渦中のメンテナがトランスジェンダーのポリコレだってことで
実名と住所を晒されて、責任取ってプロジェクト自体終わりってことになったのか

**デフォルトの名無しさん** · 2025/12/17(水) 22:29:06.78

devでtestで用いてるクレートが多いな

**デフォルトの名無しさん** · 2025/12/17(水) 22:31:21.65

>>217
rustc_codegen_gccがお荷物になってライブラリではなくてRust本体への変更が遅れるデメリットはある

**デフォルトの名無しさん** · 2025/12/17(水) 22:55:48.90

そこはこれまでもrustcとLLVMとの間の調整でやって来たことだから新たな影響は限りなく小さい
一方でRustの仕様追加変更や標準ライブラリの追加安定化などは当面rustcまわりでの独裁決定事項であることが成長中のRustにとって好ましい

**デフォルトの名無しさん** · 2025/12/17(水) 23:05:52.77

bincodeの件、斜め読みしたけど、こんな感じじゃない？

1. 生成AIのクソissueにブチ切れる
2. 脱GitHubを実行
3. ついでに、トランスジェンダーの関係で改名した新しい名前を使って過去のコミットを書き換える
4. しばらく誰も気づかない
5. 誰かがコミットIDが書き変わってることに気づく
6. うわーサプライチェーン攻撃だーと大騒ぎする
7. 騒ぎの中で、作者の実名や住所を公開する奴が現れる
8. 作者がブチ切れて、メンテナンス終了を宣言
9. ついでに、作者名の欄を独立して編集できないcrates.ioがクソ、と意見

**デフォルトの名無しさん** · 2025/12/18(木) 00:40:08.71

>>221
RFCが承認されてから10年経っても実現できない機能がいくつもある言語だからな
その程度のデメリットはいまさらだろ