[printing-japan] Re: [printing-japan] Bi-di資料
Masaki IWATA
iwata @ axe-inc.co.jp
2003年 12月 10日 (水) 08:47:54 PST
アックスの岩田です。
> どうも、BBRの吉田です。
(snip)
> > プリンタからのデータを read() しているのは、どちらなので
> > しょうか?
> > 両方で read() しているのでしょうか?
> > シグナルを捕捉した場合を想定しているのでしょうか?
>
> 質問の中の「どちら(両方)」は何を指すのでしょうか?
> bidiStartRead と bidiRead ?
こちらです。
> | プロセスタイプ:
> | プリンタステータスを勝手にプリンタから取得し続けて、それを
> | XML変換してバッファに格納しておく。また、XMLデータが準備
> | 出来たら、パイプにその旨を示すデータ(仮にA)を書きこむ。
> | データAをパイプに書きこんだ後も、プロセス側はプリンタの
> | ステータスを読みこんで、XMLデータを更新し続ける。
ということは、プロセスタイプでは、bidi*Read() の呼び出し
とは無関係に、自動的に(一定間隔で)ステータスポーリングを
行っているということですから、プリンタからのデータ read()
処理と bidi*Read() は、非同期ですね。
# bidiStartRead() 時に、read() してからサスペンドするので
# あれば、同期になりますが、それなら bidiStartRead() が呼
# ばれた時だけ read() すれば済むわけですから...
このポーリング間隔は、Bi-di Plug-in が、自発的に PPD ファ
イルから取得するということになりますね。
ということは、プロセスタイプの場合は、やはり Backend や
printer daemon で入出力の排他処理を行っても、意味がない
ですね。(bidiCtrl() 系は良く分かりませんが...)
# プロセスタイプの Bi-di Plug-in が、印刷データの出力処
# 理とは無関係に、ステータスデータの read() を行っている
# ということは、共有ライブラリタイプの場合でも、
# bidiStartRead(),bidiRead(),bidiEndRead() の手順さえ踏
# んでいれば、*任意*のタイミングで割り込ませても問題ない
# と判断して良さそうですね。(間隔はあけるとして)
> | bidiBeginRead が呼ばれたら、プロセス側はXMLデータの更新を
> | サスペンドし、XMLデータのパイプへの書きこみ準備を行う。
> | 呼び出し側は、データAを読み飛ばす。
bidiStartRead() のことですよね。
この場合、既にステータスデータがある訳ですから、ここでブ
ロックすることはないですよね。(一度も read() していないと
いうことなら、ブロックするのかもしれませんが...)
> | bidiReadが呼ばれたら、プロセス側はXMLデータを順次パイプに
> | 書きこむ。呼び出し側は、パイプからデータを順次読み込む。
ここでも、既にあるデータを吐き出すだけですから、ブロック
することはないですね。
> | bidiEndReadが呼ばれたら、プロセス側はXMLデータの更新を
> | 再開する。
> |
> | 共有ライブラリタイプ:
> | bidiBeginRead が呼ばれたら、plug-in はプリンタからステータスを
> | 読みこんで、それをXML変換する。
共有ライブラリタイプの場合は、ここでプリンタからのステー
タスデータを read() する訳ですから、ブロックする可能性が
ありますね。
> | bidiReadが呼ばれたら、plug-inはXMLデータを呼び出し側に
> | 順次返す。
ここでは、プロセスタイプの場合と同様、既にあるデータを吐
き出すだけですから、ブロックすることはないですね。
> | bidiEndReadでは特に何もしない。(read中フラグを落とすくらい?)
以上のことから、bidi*Read() がブロックする可能性があるのは、
bidiStartRead() のみであり、しかも、プロセスタイプの場合は
事実上ブロックすることはない。ということになりますが、これ
で間違いはないでしょうか?
--
IWATA Masaki
岩田 正樹
More information about the Printing-japan
mailing list