Scribble at 2022-09-29 10:00:31 Last modified: 2022-09-29 10:03:20

少なくとも現代のプロセス管理というしくみを使ったコンピュータというものは、どれほどマルチ・スレッドだの何のと言っていようと、簡単に言えばプロセスを小分けにして切り替えながら処理しているにすぎない。その切り替えがあまりにも短くて素早いからこそ、ホモ・サピエンスには並行して処理しているようにしか感じられないというだけのことである。

この仕組みは、或る原因によって特定のプロセスが「後回し」になることがあったり、そもそも処理を他のプロセスによって停止されてしまうことがある。疑わしい挙動だと判定されたら、セキュリティソフトのプロセスが或るプロセスの処理に介入して進まないようにするし、他にも大量のメッセージが一斉に発せられたせいで交通整理のために処理が一定の量に制限されたりする。これらは、アプリケーションとハードウェアとの信号処理、つまりはメッセージングという仕組みで管理されている。

メッセージングは情報科学の数学的な概念でもあるため、アプリケーションとハードウェアのあいだで信号をやりとりする状況の他にも、たとえば僕らがブラウザに表示されたフォームから情報をサーバへ送信するという状況にも当てはまる。そして、大量のメッセージが一斉にサーバへ発せられたために処理が一定の量に制限されるという現象は、一台のコンピュータの中だけではなく、クライアントとサーバという異なるコンピュータどうしの通信においても起きる。そして、そのような通信ネットワークを介した状況では、クライアントのマシンとサーバのマシンという双方のコンピュータのスペックだけではなく、途中の経路にあるインターネット・プロバイダの局舎内で動く通信機器とか、あるいは通信ケーブルの材質やコンディションなど、色々な他の条件による影響も加わって、ときとして予想できない結果を引き起こすこともある。

軽微な影響の結果なら毎日のように起きる。たとえば、僕はいまこうして Notes の記事を自宅のコンピュータに表示されているフォームで入力していて、正式に自分のサイトで公開するときは「投稿」ボタンをクリックする。投稿内容は、ローカルのコンピュータとリモートのコンピュータ（サーバ）の双方にテキスト・ファイルとして保存され、ローカルでは PHP というプログラミング言語でサポートされているファイル・システムの関数がテキスト・ファイルを所定のパスに出力し、リモートでは「バッファ」と呼ばれる一時的なデータの保管領域から、「ストリーム」と呼ばれるデータ転送のリソースに紐づけられたリモート・サーバのパスへとデータが転送されてテキスト・ファイルとして保存される。このような処理は即座に終わることもあるが、リモートはもちろん、ローカル・コンピュータ（つまりフォームを動かしているコンピュータ自身）の内部ですら、たかだか数キロバイトのテキスト・ファイルを保存する処理に何十秒もかかったり、場合によってはタイムアウトして処理が途中で止まってしまうことすらある。ましてやリモート・コンピュータに対する通信なんて、頻繁に何分もかかることがあるし、タイムアウトすることだってある。なので、いわゆる「オン書き」でフォームに文章を直にタイプしていると、何かの拍子に投稿処理がタイムアウトしてしまえば、自分のタイプした文章はたいてい消失してしまう。よって、多くの人はテキスト・エディタで下書きしてからフォームにテキストをペーストする習慣がある。僕はないがね。消えたって、たいていの文章は主旨が変わらないていどの内容で書き直せるし（東大は出ていないが、その程度の記憶力はある）、消えたからといって、その残念さは他人には分からないし些事であろう。よって、僕自身さえ残念でなければ、投稿内容が消えたって別に重大事でも何でもない。