プロセス間通信:イベント通知

Stratus VOSにも異なるプロセスの間でデータを共有ややり取りする手法が提供されてます。共有や受け取りを行うには事前にプログラミングしておく必要があります。任意のプログラム同士でデータをやり取りというのは難しいです。

簡単な通信の1つにイベント通知があります。AプロセスからBプロセスが通信を行うとすると、Aプロセスからイベント通知APIを呼び出すとBプロセスへ通知され、Bプロセスはイベント通知のイベントが発生します。当然Bプロセスはイベント通知を受けるためにイベント通知のイベントを待っている状態でなければなりません。イベントは実ファイルを使って処理されます。最初に実ファイルパス名を決定し、s$attach_eventというAPIを呼び出してイベントの用意をします(ABプロセス双方とも)。Aプロセスは通知にs$notify_eventというAPIを呼び出すことで通知処理を行います。Bプロセスはイベントの用意後に戻されたIDとカウントを使用してs$wait_eventにてイベントを受けるまで待機します。(他のイベント待ちする処理も行っておく)Aプロセスから通知されるとs$wait_eventから抜けてくるので、s$read_eventというAPIでイベント通知を受けます(当然の処理として、待機する何のイベントが発生したのかチェックする必要がありますが)。これで通知されたことによる各種処理を実施することになります。イベント通知には4バイト(fixed bin(31)サイズ)のイベントデータの受け渡しも可能です。これを超えるデータを渡したい場合は、別の手段を使う必要があります。

イベント通知は、何らかのファイル作成をしてその完了を通知するとか、簡単なプロセスへの制御などで使われる可能性があります。まあ、ファイルも巨大でなく、レコード単位の受け渡しだとキュー通信を使った方が処理が簡単になります。また、プロセス間通信ではないですが、タイマーイベントという一定時間経過したらOSから通知してね・・・みたいな使い方もできます。イベントの用意をしたら、s$set_time_eventというAPIで秒数を指定してイベントを待機し、通知されたイベントを判定してタイマーイベントなら当該処理を行うという使い方をします。イベント通知が不要になったらs$detach_eventでリソースを解放します。プログラム終了時にも解放されますが、自分が使ったリソースは自分で解放した方がマナーがいいと思いますし、ルーチンを別のプログラムへ流量したときに解放し忘れがなくなると思われます。

同期・非同期モードとイベント

久々にVOSの話でも。

Stratus VOSのI/O動作には同期モードと非同期モードがあります。ファイルを読み書きするときは通常デフォルトの同期モードで行われ、オペレーションが完了すればI/O動作も終わってる状態となります。短時間で処理される動作なら同期モードでも支障ありませんが、通信などでいつ読み込まれるかわからない場合では同期モードでは処理が止まってしまいます。
例えば、内部的なコマンドを受け付け処理と外部からのデータ受信処理を行うプログラムを作る場合、2つの事象(イベント)を同時に処理する必要があります。これが行われてないと、外部データを読み込みしてる間に内部コマンドが届いても処理できなくて困ってしまいます。そこで登場するのが非同期モードです。
非同期モードは通信やキューなどのプロセス間通信で使用されます。ファイルI/Oでも使用できますが逆に処理が煩雑になります。読み取りで威力を発揮し、読み取り動作を行うとデータがあればデータを戻し、無い場合は受信のイベントを待てという指示としてe$caller_must_waitというエラーコード(実コードは1277)を戻します。そしてプログラムは受信などの動作が完了時に通知されるイベント通知をもって処理再開を行います。イベントを待つのにs$wait_eventというAPIを使用し、処理が完了するとイベント通知されたかわかるという仕組みです。上記の例のプログラムだと、内部コマンドを受け取るイベントと外部データを受け取るイベントの2つを待ち、発生したイベントを判断してそれぞれの処理を行えばいいわけです。これで外部データ受信待ち中に内部コマンドでプログラム停止命令などを受けると正常に終了させられたりできるわけです。
VOSではポートを介して一貫したイベント処理とI/O処理を提供してくれるので、あらゆるI/O動作を簡単に処理できます。これが通信に強いとされる根幹です。

過去の記事など

サーバの改変とかで一部画像データが吹き飛んでましたが、残ってる画像データで何とか復元しました。
消えて完全になくなったのは諦めですが。
一時期、画像のuploadフォルダ内にウィルスとうかBOTを仕込まれたことがあり、そこでの対応で一気に消したのがまずかった。

なかなか投稿できなかった

K/C関係の打ち込みはTwitterへ投稿してたのでなかなか投稿できませんでした。Amazonのアフェリエイトも拒否されたので辞めました(もともと収入が皆無だったけど)外部に置いてるトップページは自分のサーバへの入り口にしか使ってないのと、自サーバトップページからは何もリンクしてないので作りかけと思われたらしい。まあ、よほどアクセスがない限りリンクを踏んで購入してもらえないので収入の見込みがないのはわかってましたけどね。
ちなみに、Google Adsenseもうちみたいな使い方だと稼げません。5年くらいかけて数千円入るかってところです。よく見かける外部リンクだらけの広告ページを作らない限り収入を得るのは難しいでしょう。

MZ-2000関係ですが、FM音源プラグインを作ろうと思って試行錯誤していたこともありました。まだ勉強不足で進んでませんけどね。Gens(Genesisエミュレータ)のソースを参考にFM音源部分のソースを抜き出して使ってみるつもりが、なかなかうまく行かなくて停止中です。自分がGens側の動きを理解しきれてないので音を出すための初期処理をどんな風にやればいいのかわからない、MZ本体からOUTで受けとるデータをどうやって受け渡せばいいのかもわからない・・・そんな状態です。ハードエミュレーションは知識あってのことでしょうけど、手取り足取り教えてもらえるわけでもないので、他人のソースを読んで理解して利用するしかないのでしょうね。
MZ本体とのやり取りは以前プラグインを作ったので出来てるのですけどね。自分でFM音源データを元にDirectSoundを叩くのがいいのか?とか思案中。

ファイルI/O

Stratus VOSでファイルI/Oを行うには次の手順でアクセスします。
1.ポート接続(s$attach_port)
2.オープン(s$open)
3.I/O(s$xxx_read,write)
4.クローズ(s$close)
5.ポート切断(s$detach_port)

この手順は、ファイルに限らず通信プログラムを書く場合も流れが同じです。まあ、プロトコルが違えばいろいろと設定が必要なので多様なルーチンコールが必要になりますけど。ポートを介してのアクセスという点からではこの流れという。

s$attach_portに指定する必須パラメータは、パス名のみ。パス名はシステムが認識するフルパス名(システム名、ディスク名、ファイルパスをすべて含む名前)を指定しなければ失敗します。よく使われるのは、s$expand_pathルーチンで相対パス名を指定してフルパス名を取得して与えるという感じです。ポート名はNULL文字列を指定すると、ランダムな名前を付けてくれるので、NULLでも問題ないです。まあ、プロダクツを作るなら名前を決めておくのが間違いないですし、誤って複数回attachさせてしまっても間違いに気づきやすいですので。戻される重要な値に、ポート番号があります。以後、ファイルアクセスには、割り当てられて戻されたポート番号を使います。(C言語でいうFILE*みたいなものです)

s$openでファイルをオープンしますが、既存のファイルを読み込みのみでオープンする場合は非常にパラメータがシンプルになります。書き込みや更新(読み書き)の場合は、ファイル属性やレコード長などのパラメータが必要です。あと難易度を高めてるパラメータにロッキングモードがあり、ファイルやレコード単位のロック機構を利用する場合、ファイルを利用するシステム全体で統一しなければなりません。ログみたいなファイルを読み込みモードかつロック無視なら、大半のパラメータは指定しても無視されるので、簡単にオープンできます。

ファイルI/Oはファイル属性やキー順ファイルなどによって異なります。s$rel_で始まるルーチンは固定・相対ファイルに使用し、s$keyed_で始まるルーチンはキー順ファイルに使用します。s$seq_で始まるルーチンはシーケンシャルファイルといった感じです。それと、ロッキング機能も併せてプログラミングしなければなりません。この辺りが一番の肝ですかね。

s$closeでファイルをクローズします。書き込みを行ってる場合は、最終的なフラッシュも行われます。ここで再度オープンすれば再度アクセスすることもできます。

s$detach_portでポートを切断します。この呼び出しで、ファイルを切り離しポートの接続情報をクリアします。

WordPress5.0

つい勢いで、エディタを昔のものに戻してしまった。新しいものを使っていかなければついていけなくなるのですけど、慣れた環境を手放すのは厳しいところです。今まで書いていたことが、そのまま新しい環境で通用するようなやり方が簡単に移行できるかってのが移行できるポイントですかね。この敷居が高いと昔のものに戻さないとって思ってしまう。しばらくしたら新エディタを使いつつ移行してみようと思う。

sSMTPのAuthPath

先日Googleアカウントからセキュリティ警告があったので何気に設定したらThunderBirdでメール受信できなくなるわ、パスワードを強制変更させられたりして大変だった。まあ、真意を知らずに設定した自分が悪いのですけど。

パスワードを変更したらsSMTPのパスワードも直さないとと思っていつも通り直したのはいいのですが、サーバからのメールが転送されないことに気づきました。まあ、原因はパスワードエラーなのですけど、AuthPathに指定できない文字がまだ存在してたとは。過去、Googleアカウントで使える文字のうち、一部sSMTPで使えない文字があると気づいてましたけど、久々パスワード変更だったので忘れてました。しかも未だに直ってないという。

現状では、AuthPathにシャープ記号やイコール記号は使えないです。独自のエンコード処理をしており、それらが特別な意味でつかわれているらしいです。数年前にこの事実を知ってたのですけど、すっかり忘れてた。未来永劫使えないっぽいので、ダメな記号はパスワードに加えないようにしないと。

SPACE PANIC


マイコンゲームの本3掲載。アーケードゲームの移植です。当時、田舎だったので実際のゲームは見たことがないですが、ゲームセンターあらしで使われていたので存在は知ってました。PCGを使用し、FORMで書かれてるので速度も速く、快適に遊べます。

COSMO SHOOT


マイコンゲームの本3掲載。編隊を組んで攻撃してくる敵を打ち落としていくゲーム。イメージ的にはギャラガのボーナスステージが攻撃してくる感じでしょうか。トリッキーな動きで狙い撃ちが結構難しいです。