[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