[printing-japan] Bi-di資料

Yasumasa TORATANI toratani.yasumasa @ canon.co.jp
2003年 12月 4日 (木) 19:06:39 PST


虎谷です。

On Fri, 05 Dec 2003 11:21:34 +0900
Masaki IWATA <iwata @ axe-inc.co.jp> wrote:

> アックスの岩田です。
> 
> > 虎谷です。
>   (snip)
> >>bidiNew() には、引数にプリンタポートの fd が含まれていない
> >>ようなのですが、どのように制御されるのでしょうか?
> > 
> > プリンタポートは、Bi-di Plug-inの呼び元がオープンして、
> > bidiNew関数の引数として渡します。
> > 通常の場合、fdRead == fdWriteとなりますが、それらが異なる場合も
> > 想定して、2つのfdをbidiNew関数に渡すようにしています。
> 
> すみません、質問の仕方が明確ではなかったようです。
> 
> process タイプの起動時には、
>   --data-write-fd
>   --date-read-fe
>   --cmd-write-fd
>   --cmd-read-fd
>   --output-fd
>   --printer-uri
> の、計 6 個のパラメータ引数があり、--printer-uri を除く 5 個の
> パラメータが必須であるという事だと思うのですが、shared library
> タイプの場合の、bidiNew() での引数との対応が、
>   --data-write-fd == fdWrite
>   --data-read-fd  == fdRead
>   --cmd-write-fd     (不要)
>   --cmd-read-fd      (不要)
>   --output-fd        該当なし?
>   --printer-uri   == pURI
> ということになると思うのです。
> (この対応づけで勘違いしているのでしょうか?)
> 
> で、質問の意図したかったことは、--output-fd に相当するプリンタ
> ポートのファイルディスクリプタを渡す方法は、どのようになってい
> るのでしょうか? ということです。

共有ライブラリ型の Bi-di Plug-inの場合、文字通り共有ライブラリ
なので、上記引数によって fd を渡すことはないのですが。。?

共有ライブラリ型の Bi-di Plug-in moduleは、呼び元と同じプロセス
なので、呼び元の fd がそのまま使えます。

(中略)

> >>ところで、ジョブのキャンセル処理なのですが、bidiCancelJob()
> >>は、CUPS からのキャンセル指示のためにあるものだと思うのです
> >>が、これをプリンタステータスユーティリティからも指示できる
> >>ようにするというような予定があるのでしょうか?
> > 
> > CUPSからということは、Type Aですよね。
> > 
> > CUPS からジョブのキャンセルが発行されると、backendには
> > SIGTERMが発行されます。backendは、SIGTERMを受信したら
> > ジョブのキャンセル処理を実行するようにします。
> > 
> > ジョブのキャンセル処理では、bidiCancelJob、bidiEndJob, 
> > bidiDestroyが呼ばれなければなりません。
> 
> この質問で最終的にお訊きしたいのは、CUPS を経由せずにジョブの
> キャンセルができるような構造も*あり*だということになると、ア
> プリケーションから出力されたデータが、一連の処理の流れの中の
> どこの段階でスプールされているのか、逆に辿る必要がでてくるの
> で、このようなお考えをお持ちなのかどうか、ということなのです。
> というか、これは*なし*にして下さいませんか? というお願いです。

*なし*にするかどうかは、私は決められないのですが。。(^^;
多分に、printer daemonの仕様に掛かってるように思います。

現時点で見えている処理の流れでは、
Type Bのステータスユーティリティは、printer daemon と繋がって
printer daemon に含まれる特定のプロセス(出力プロセス)が
Bi-di Plug-inを起動することになっていたと思います。

このような系で、Type Bがキャンセルを実行する場合、その要求は
先ずprinter daemonに伝えられ、最終的に上記出力プロセスに
伝えられて、そのプロセスが bidiCancelJobを呼ぶことになると
思います。この場合、キャンセルはCUPSを経由しないことになります。

さらにこの場合、キャンセルに関する情報を backend側に伝達する
必要があると思います。(printer daemonがスプールしない、かつ
backendが、まだprinter daemonと繋がっている=印刷データの
転送が完了していない)

伝達方法については、backendとprinter daemonの間のプロトコル
に依存すると思います。

> >>>また、fd を利用する場合も、bidiStartRead(),bidiEndRead() を
> >>>発行する必要があるということでしょうか?
> >>
> >>バッファの問題は、こちらの場合について、お尋ねします。
> >
> > すみません。
> > 質問の内容が、よくわかりません。。(^^;
> 
> これまた、変な訊き方をしてしまいました。
> 
> 問題になるのは、多分 write の場合だと思うのですが、
> ファイルディスクリプタへ直接データを write() するような処理
> が許されている場合(shared library タイプでは有り得ないのかな?)
> では、
>   bidiStartWrite();
>   write(fd,...);
>   bidiEndWrite();
> という手順を踏まなければならないのでしょうか?

いいえ。writeをそのまま呼んで構いません。
bidiWriteがサポートされない時は、bidiStartWriteや、
bidiEndWriteもサポートされない、という仕様です。
その辺りは、bidiGetCapで判別します。

> read の場合を考えると、こんな手順は踏めないので、多分この段階
> で間違っているのだと思いますが...
> 仮に、このような手順が必要なのだとすると、書き込み側が write()
> 直後に bidiEndWrite() を発行してしまうと、読み出し側での読み
> 出し処理が行なわれる前に、bidiEndWrite() を受け取る場合がある
> ように思います。この場合、バッファに残っているデータはどのよ
> うに扱われるのかということなのですが...
> 
> でも、よくよく考えると、(パイプ?の)ファイルディスクリプタに対
> して、直接 read(),write() するのは危険すぎますね。

共有ライブラリ型の場合、bidiWriteがサポートされない Bi-di Plug-in
moduleは有りだと思います。(弊社のBi-di Plug-in)

一方、プロセス型のBi-di Plug-inの場合には、bidiWriteのサポートを
前提としていました。(EPSON KOWAさんの Bi-di Plug-in)

しかし、その辺りの記述がドキュメントにないですねぇ。。(^^;
プロセス型で、bidiWriteサポート無しの場合も、有りえないことは
ないのですが、当面の仕様として、「プロセス型の場合は、bidiWrite
のサポートは必須」を追記したいと思います。

-----------------------------------------
Yasumasa TORATANI
Computer Technology Development Dept. 12
CANON INC. Shimomaruko Office, Japan





More information about the Printing-japan mailing list