
Ubuntu日本語フォーラム

ログインしていません。
Thunderbirdで新規メールを作成中(文字入力中)に、メールの受信確認が動くと入力動作が、停止してしまいます。受信確認が終わるとまた作業を再開できるようになります。これは、プログラムロジック上正常な動きですか。
オフライン
hotohoto です。
「Nice値」を大きくしたらどうでしょうか?
私はGUIの「システムモニター」(無かった導入してください)で変更しています。
具体的には、
システムモニターの中の「プロセス」を選ぶ。
その中で遅くしたいソフトを探す。
その行の上で右クリックする。
「優先度の変更」を選ぶ。
数字を変更する。
です。
なお優先度を下げるときにはそのままできるでしょう。しかし下げるときにはsudoの権限が必要です。
オフライン
hotohoto さん
回答有り難うございます。質問した事自体はどうなのでしょうか。そういうロジックになっているのですか。
オフライン
arata による投稿:
hotohoto さん
回答有り難うございます。質問した事自体はどうなのでしょうか。そういうロジックになっているのですか。
すみません、途中でおくってしまっていました。
そのnice値を大きくすることがどんな効果を齎すかですが、
ほかのタスクが現れた場合にthinderbirdのタスクを後回しにし、早く動かしたいアプリを動かすことができる、
というものです。
なお、この方法に有効なのは、指定したタスクだけです。
アプリが副次的に使っている仮想でのネット関係のタスクが別になっていたりすれば該当しないでしょう。
つまりその遅くしたい対象のアプリが必ずしも目的の合っていない場合があります。
そういった場合は効果が出ません。
また目的のアプリだとしても、別途の物理的な速度が遅いとか容量が低いとかほかの何かによって
効果が出ないということは有ります。
そういえばthunderbird はかなり昔使ったことがありますがリソースをよく消費したなと言う覚えがあります。
私はSylpheedですが、thunderbirdよりましでも受信の際は結構ほか影響与えます。
だから優先度は下げていますね。
オフライン
>新規メールを作成中(文字入力中)に、メールの受信確認が動くと入力動作が、停止してしまい
>ます。
とあるので、どっちのプロセスもthunderbirdなのでは?
挙動がどうなのかは、ちょっとすぐ試せないのでわからないのですが、同一プロセスの中の処理で優先順位を変更しても、エディタの側の処理は帰ってこないのではないかと思います。
昨今だと普通はマルチスレッドで書かれているので、送受信とは別スレッドでエディタなどが動作しそうですが、このケースの場合受信処理をしているときにThunderbird内で、別スレッドは停止しているのか正しい挙動なのか?という話のように思います。
使ってる人が見れば再現性の確認で挙動は確認できそうではありますが。
オフライン
artemis による投稿:
>新規メールを作成中(文字入力中)に、メールの受信確認が動くと入力動作が、停止してしまい
>ます。
とあるので、どっちのプロセスもthunderbirdなのでは?
挙動がどうなのかは、ちょっとすぐ試せないのでわからないのですが、同一プロセスの中の処理で優先順位を変更しても、エディタの側の処理は帰ってこないのではないかと思います。
昨今だと普通はマルチスレッドで書かれているので、送受信とは別スレッドでエディタなどが動作しそうですが、このケースの場合受信処理をしているときにThunderbird内で、別スレッドは停止しているのか正しい挙動なのか?という話のように思います。
使ってる人が見れば再現性の確認で挙動は確認できそうではありますが。
なるほど最近のthunderbirdはそうなんですか。
それでは違う原因のようですね。
受信中に送信メールを書くと何かしらがバッティングするのかな?
それだと根本的なバグが在るのかもしれません。
そうすると障害を避けるためには、運用でその状況を回避するのが消極的な解消法でしょう。
その方法は「新規メールを書くときには、受信しない。」ということです。
つまり自動受信を解除しておくということになりますね。
送信メールを送る前か後に手動で受信することです。
オフライン
arata による投稿:
Thunderbirdで新規メールを作成中(文字入力中)に、メールの受信確認が動くと入力動作が、停止してしまいます。
自分の環境(Ubuntu 16.04.3LTS & Thunderbird52.3.0(共に64ビット版))ではそのような現象は発生しません。送受信していても快適に文字入力は出来ます。
*質問する場合はPCの環境は書いたほうがいいですよ。第三者からはどの程度のスペックのPCを使っているのかわかりませんから。
オフライン
opanchi_1963さん
KUbuntu 16.04.3 LTS(32 ビット)
Thunderbird 52.3.0 (32 ビット)
です。
artemisさん
ご理解いただきありがとうございます。質問の趣旨はその通りです。過去メールを全て保管していて、良い環境ではないため、これも影響しているのかもしれません。opanchi_1963さんによると、64ビットでは起きないみたいですね。
メールが繁華に来る環境ではないので、致命的ではなく放置していましたが、本来はどうなんだろうと気になって質問しました。
オフライン
arata による投稿:
メールが繁華に来る環境ではないので、致命的ではなく放置していましたが、本来はどうなんだろうと気になって質問しました。
Thunderbirdへアドオンとか入れてるのなら、アドオン無効のセーフモードでも同様なのか、検証してみるといいですよ。
オフライン
Thunderbird のアドオンが悪さしている可能性の他に、メモリ不足とか、NIC のドライバーが古いとか、NIC 自体の性能不足とか、
オフライン
hotohoto による投稿:
なるほど最近のthunderbirdはそうなんですか。
いえ、質問内容が、同一プロセス内での処理の並列性ではないか?という話で、実際の挙動について正しいか?というものだという話をしただけです。
nice値の変更は別プロセスと併用したときに特定のプロセスが資源を全力で持っていくときには有効だと思うので、エディタとMUAなど、別のソフトの併用時を想定していると思ったので。
マルチスレッドで書かれているかはわかりませんが、psコマンドの-Lオプションでスレッド単位で表示できるはず。
別スレッドで処理してくれてないと出てきませんが、化石みたいな実装じゃなければ依存関係が強い処理以外は並列処理されるようになってるのがイマドキだと思うので、素直にかかれてれば、送受信してるスレッドが少々処理が多くても別のスレッドも稼動するはず…なのですが。
余裕はあるけど、処理を戻していないのか、優先順位で全部もってっちゃってるのか位は確認できるんじゃないかと。
あと、別プロセスも併用した場合そっちもとまるのか?なんてのも挙動のヒントにはなりそうな気がします。
資源に余裕があるのなら、普通に何らかの事情で挙動として処理を返していないか、エディタに処理を渡していないので、原因は気になるところではありますが。
オフライン