[printing-japan] Re: [printing-japan] Bi-di資料

Masaki IWATA iwata @ axe-inc.co.jp
2003年 12月 9日 (火) 07:18:37 PST


アックスの岩田です。

> 中村です。
  (snip)
> CUPS からのキャンセルが backend に影響するのは、印刷中のジョブを実行中の
> backend の場合であり、この場合、CUPS から backend に対して、SIGTERM( or 
> SIGKILL)の signal が送られますので、SIGTERMの場合には、それがトリガーに
> なるかと思います(スプール中のジョブは除きます...)。

CUPS 標準の Backend のソースをみると、SIGTERM は無視して
いたり、そのまま exit() していたりしますね。
# IPP の仕様では、データの出力が開始されてしまったジョブ
# のキャンセルや停止は、実装依存となっていたように記憶し
# ていますので、これでも良いのですね。

但し、この方法では、先般 bidiCancelJob() に追加された
idJob を利用した(高度な)キャンセル処理という訳にはいきま
せんね。
# カレントの Backend が処理しているジョブ(のみ)をキャン
# セルするということになりますね。

IPP Backend の場合は、部数分のジョブに分割される場合もあ
るようですので、ちょっと複雑になりますが...(printer daemon
が複数部印刷に対応すれば良いということなのですが...)
しかも、SIGTERM を受け取ると、テンポラリファイルを削除す
るだけですぐ exit() しているので、その先ではコネクション
の切断で判断するしかないような気が...(ということは、ステー
タスを返すことができないですね...)
これまた、処理が複雑になりそうですね。

> BIDI_CAP_JOB capabilityを持っている Bidi plugin を使う backend または、
> Printer Daemonは、bidiCancelJob()を発行を実装に含める必要があるかと
> 思います。

printer daemon でも、やはり要りますかね?
CUPS からのキャンセル処理が、うまく下流に下りてくるよう
なので CUPS にキャンセル処理を投げてしまうという手があ
るのですが...どんな方法をとっても、複雑になりますね。

--

他に、bidiCtrl() で何らかの制御が行えるようになったとし
ても、CUPS 経由では利用できないということで、良いのでしょ
うか?
# Backend は SIGTERM によるジョブキャンセル以外のプリン
# タ/ジョブの制御/操作は対応できないということで良いの
# でしょうか?

--
IWATA Masaki
 岩田 正樹






More information about the Printing-japan mailing list