| 1 |
SATELLITE プログラマーの為の指針 (メモ書き) |
| 2 |
|
| 3 |
$Id: CodingStyle.sjis,v 1.1.1.1 2004/03/31 08:15:05 orrisroot Exp $ |
| 4 |
|
| 5 |
1) メモリ管理について |
| 6 |
|
| 7 |
現在, SATELLITE プログラムを進める上で, メモリ管理を行うことのできる |
| 8 |
関数として, |
| 9 |
|
| 10 |
* System Call (malloc, free, calloc, realloc), |
| 11 |
* C++ Library Interface (new, delete) |
| 12 |
|
| 13 |
モジュール開発の中で利用できる API として, 上記に加え SATELLITE API |
| 14 |
として, |
| 15 |
|
| 16 |
* SATELLITE low level memory API (emalloc, efree), |
| 17 |
* SATELLITE Buffer API (AllocBuffer, FreeBuffer, CAllocBuffer) |
| 18 |
|
| 19 |
が存在し, 混在している状態にある. |
| 20 |
|
| 21 |
今後, 開発を進める上でどの関数を何処で利用すればいいのか ? と疑問 |
| 22 |
に思う部分がでてくることが予想されるため, ざっとまとめておく. |
| 23 |
|
| 24 |
a) libsatellite, libslshell, shell に関して |
| 25 |
|
| 26 |
* 基本的に int, double, char , struct などの C 言語のデータ型 |
| 27 |
に関しては, System Call を利用する. |
| 28 |
|
| 29 |
* C++ の クラス のインスタンス作成に関しては, C++ Library |
| 30 |
Interface を利用する. |
| 31 |
|
| 32 |
* メモリの管理をそれぞれの処理で徹底し, 終了時の解放し忘れをなくす. |
| 33 |
|
| 34 |
* メモリの確保と解放は同一ライブラリ内で必ず行う．これを怠る場合 |
| 35 |
Windows で致命的エラーとなる． |
| 36 |
|
| 37 |
b) モジュール開発に関して |
| 38 |
|
| 39 |
* GetSeries(), GetSnapshot(), GetString() で取得したメモリは, |
| 40 |
SATELLITE API により, 動的に確保され, メモリ領域が管理されてい |
| 41 |
るため, コマンドの関数終了前に FreeBuffer() もしくは, efree() |
| 42 |
によって解放しておく. |
| 43 |
|
| 44 |
* ReturnSeries(), ReturnSnapshot(), ReturnString() で返したメモリ |
| 45 |
領域は, これらの関数内で複製されるため, コマンドの関数終了前に |
| 46 |
efree() によって解放しておく. |
| 47 |
|
| 48 |
* 必ず, System Call のみ, SATELLITE API (low level memory API もし |
| 49 |
くは Buffer API )のみ といった形で対となる関数を利用する. |
| 50 |
|
| 51 |
* glib など独自でメモリの管理を行うライブラリ関数を呼び出している |
| 52 |
場合は, System Call や C++ Interface, SATELLITE API を利用せず, |
| 53 |
適宜その対応するライブラリ関数を利用する. |
| 54 |
|
| 55 |
* thread を生成して, コマンドが終了してしまう場合は thead 内から |
| 56 |
参照されるメモリに対しては, SATELLITE API を利用してはならない. |
| 57 |
|
| 58 |
* strdup() を利用して確保されるメモリに対しては, SATELLITE API を |
| 59 |
利用してはならない. |
| 60 |
|
| 61 |
* これから, 新規に開発するモジュールに関しては, コマンド内での動的 |
| 62 |
メモリ確保 に関しては, System Call, C++ Interface をなるべく利用 |
| 63 |
するようにする. |
| 64 |
|
| 65 |
* メモリの確保と解放は同一ライブラリ内で必ず行う．これを怠る場合 |
| 66 |
Windows で致命的エラーとなる． |
| 67 |
|
| 68 |
c) 参考までに. |
| 69 |
|
| 70 |
* SATELLITE API について |
| 71 |
|
| 72 |
SATELLITE Buffer API は, SATELLITE low level memory API のラッパー |
| 73 |
関数であり, その実体は, emalloc, efree で実現されている. |
| 74 |
|
| 75 |
SATELLITE low level memory API および SATELLITE Buffer API で利用 |
| 76 |
されるメモリは, 現状 SATELLITE の shell がリストで管理しており, |
| 77 |
そのコマンド呼び出しが終了すれば, 自動的に解放されるように設計され |
| 78 |
ている. |
| 79 |
|
| 80 |
SATELLITE 2.9x では, 個々のコマンドが独立したプログラムとなっていた |
| 81 |
ために, プロセス終了時に自動で解放されることを想定し, 確保したメモリ |
| 82 |
をほとんど解放しない実装となっている. 一方, SATELLITE 4.x では, 各 |
| 83 |
モジュールのコマンド呼び出しを同一プロセス上で関数として呼び出すこと |
| 84 |
によって実現している. |
| 85 |
|
| 86 |
このため, SATELLITE 2.9x の資源をある程度そのまま引き継ぎ, かつ, |
| 87 |
メモリの解放し忘れを防ぐための手段であり, ad-hoc な実装であることを |
| 88 |
念頭におかねばならない. |
| 89 |
|
| 90 |
* 将来的には, 以下の方針を持って開発を進める予定 |
| 91 |
|
| 92 |
0. SATELLITE API を obsolete な関数とし, 利用しない方向に進む. |
| 93 |
|
| 94 |
1. 全モジュールの全コマンドのソースのメモリ管理を見直し, 各モジュール |
| 95 |
は, そのモジュール内もしくは コマンド内で責任を持ってメモリ管理を |
| 96 |
行うように変更する. |
| 97 |
|
| 98 |
2. 1. の変更が完了次第, SATELLITE low level API および SATELLITE |
| 99 |
Buffer API で利用されるメモリを SATELLITE 側でも管理しないように |
| 100 |
する. |
| 101 |
|
| 102 |
3. 全 SATELLITE API を System Call もしくは C++ Interface に書き換える. |
| 103 |
|
| 104 |
4. SATELLITE メモリ管理 API の徹底 ? |
Parent Directory
Revision Log
Revision Graph