memo: 2003年 12月 | 現在時刻:2024/11/23 18:21:46 |
---|
2002 / 2003: 1 2 3 4 5 6 7 8 9 10 11 12 / 2004 / 2005 / 2007 / 2008 / 2010 || 日付順/逆順 || 月毎/週毎 || 全文検索 | sysworks |
24日(水): 近況 |
| ||
---|---|---|---|
そろそろ4週間たってしまうわけですが…、忙しいのです。 ある意味、あの時プレリリース出してて良かった。 たくさんある実装予定の機能の中で ・1コネクション多アカウントのための仕組み ・新着メールの個別通知クリックでメールプレビュー の2つをやっと実装したところ。 もっともこの2つで残りの作業量の80%を占めていたと思うので残りは楽。 今週末ぐらいにIMAPやメールのデコード周り以外の機能を実装したバージョン (プレリリース2になるか、本リリースになるか未定) をだせるといいな。 現在220KB。 ・マルチスレッドでの終了処理について Riffは各アカウントごとに個々のスレッドをもってるのですが スマートに(メインスレッドを停止させることなく)各スレッドを終了させ、 かつ、確実にTerminate時に全てのスレッドを終了した状態にするのはちょいと難しいです。 System/Exitが呼び出された後はメインスレッド以外のスレッドからサービスを呼ぶと、 サービス呼び出しが実行されず、そのスレッドがとまってしまいます。 Terminateの中でそのようなスレッドが終了するのを待つと、どちらも止まったままとなり デッドロックに陥ります。 いろいろな試行錯誤の後、結局RiffではSystemモジュールがサービスのディスパッチとして やっている処理を自モジュールのTerminate関数内で行って、 メインスレッドがTerminate内にいる状態でも他スレッドからのサービス呼び出しが 停止しないようにして対処しています。 ただ、System/Exit以降(≒Terminate呼び出し以降)のサービス呼び出しは 基本的に考えられていないと思うので、呼び出すとしてもSystemモジュールの サービスにとどめておくべきでしょう。 ・通知サービス(UI/Notify)について UIモジュールの基本サービスである通知は、スレッドをブロックすることなく かつ、ユーザがアクションを取らなくても一定時間で自動的に閉じるという点で ユーザに重要ではない通知をするには非常に便利です。 通知サービスでは通知に対するクリックをコールバックという形で受け取ることができますが、 上に書いたようにスレッドがブロックされないため、 プロトコルプラグインの場合は下手すると通知がクリックされたときには 対応するコネクションが閉じられているという可能性があります。 通知サービスのコールバックではコールバック関数とその関数に渡す1つの(4バイト)整数を 指定できます。通常、整数1つでは情報が少なすぎるので整数値としては何らかの構造体への ポインタを渡すことになります。 しかし、コネクションに対応して格納されているデータの場合は コネクションが閉じられるとそのデータも通常は削除されてしまいます。 そうするとコールバック関数に渡されるデータが無効なポインタとなってしまい、 場合によっては通知をクリックするとアクセス違反の発生や、 そうでないにしても予期しない動作をしてしまう可能性があります。 この問題に対してすぐに思いつく対処法としては 1.通知はその表示時間をプラグイン側から指定できますので、 表示時間を経過するまでポインタの先のデータを保持するようにしておく。 2.ポインタの先のデータをコネクションと関係なく、本体が終了するまで 保持しておく。 3.ポインタを使わない。 1.は実装がそこそこ面倒です。 参照されるデータ構造に参照数カウンタをつけて参照数が0になったときにデータ構造を 削除するようにし、 1.データ構造の参照数カウントアップ 2.データ構造へのポインタとともに通知サービス呼び出し 3.タイマにデータ構造の参照カウントダウン用ルーチンを登録 といったところ。 この方法では何らかの理由で通知が指定より長く表示されてしまった場合には 問題が発生する可能性があります。 2.は実装は簡単ですがメモリが開放されないので 長期間利用すると多くのメモリを消費することになるでしょう。 3.ポインタを使わないと情報が足りないからポインタを使おうとしているのに ポインタを使わないとはアホか。と思わないでもないですが、 場合によってはこれで何とかできます。そしてRiffはこれを使っています。 4バイトの整数にコネクションNo.(1バイト)、アカウントNo.(1バイト)、 メールNo.(2バイト)をもたせて一種のポインタとし、 この情報を元に表示すべきメールを探索しています。 コネクションが256個、コネクションごとにアカウントが256個、 アカウントごとにメールが65536通が扱える最大数となりますが、問題ないでしょう。 |
11日(木): 致命的に暇がない |
| ||
---|---|---|---|
すみません時間ないのに40時間ほどバテンカイトスやってました…。 |
1日(月): Riff |
| ||
---|---|---|---|
かなーり、中途半端ですがここで出さないとまた1週間遅れそうなのでプレリリース。 現状、アカウントの設定がわかりにくすぎるのでこれを何とかしたい。 予定では1コネクション多アカウントと1コネクション1アカウントを同時実装するつもり。 1コネクション多アカウントは従来どおりにオプション設定からの独自プロファイル方式。 1コネクション1アカウントはpop://user@host:port/textな感じでアカウント名を指定する方法と オプション設定での独自プロファイルに名前をつけてそれをアカウント名にする方法とを考えている。 それにしても 偽MC3.2 42KB + nMail 45KB = 87KB CMail 100KB に対して Riff 196KB って…。やはりSTLの使いすぎなんだろうか…。 今気づいたが、プレビューの送信日時と宛先、逆にしたままだ… |
2002 / 2003: 1 2 3 4 5 6 7 8 9 10 11 12 / 2004 / 2005 / 2007 / 2008 / 2010 || 日付順/逆順 || 月毎/週毎 || 全文検索 | sysworks |