SunOS リファレンスマニュアル 5 : 標準、環境、マクロ

attributes(5)

名前

属性, アーキテクチャー, 使用条件, CSI, 安定性, MT レベル– インタフェースの属性

機能説明

マニュアルページの「属性」セクションには、属性タイプと対応する値を定義する表 (下記を参照) が含まれます。

属性タイプ	属性値
アーキテクチャー	SPARC
使用条件	SUNWcsu
CSI	有効
インタフェースの安定性	不安定
MT レベル	安全

アーキテクチャー

アーキテクチャーはプロセッサまたは固有のハードウェアを定義します。uname(1) の -p オプションを参照してください。必要なアダプタまたは周辺機器を示す場合もあります。

使用条件

これは、マニュアルページで説明されているコマンドまたはコンポーネントを含むソフトウェアパッケージを示します。このコマンドを使用できるようにするには、示されたパッケージがインストールされている必要があります。パッケージの追加方法についての詳細は、pkgadd(1M) を参照してください。

コードセットの独立性 (CSI)

どのコードセットの特性にも依存していない OS ユーティリティーおよびライブラリは、コードセットの独立性 (CSI) を保持している、と言われます。これらは、CSI が有効な属性を持っています。これは、たとえば拡張 UNIX コードセット (EUC) でのみ動作するような、多くのコマンドやユーティリティーとは対照的です。EUC は、同時に 4 つまでのコードセットをサポートできるエンコーディング方式で、一般にアジア地域の文字セットを表すために使用されます。

ただし、実用上の理由によりこの独立性は絶対ではありません。現在の CSI 実装には、まだいくつかの仮定が適用されています。

ファイルコードは ASCII のスーパーセットです。
複数バイト文字および NULL で終わる UNIX ファイル名をサポートするため、NULL および / (スラッシュ) 文字を、複数バイト文字の一部に含めることはできません。
「ステートレス」ファイルコードのエンコーディングだけがサポートされています。ステートレスなエンコーディングでは、単一のシフトは除外されていませんが、シフト、ロッキングシフト、指示、呼び出しなどは避けられています。
プロセスコード (wchar_t 値) は実装に依存し、時期によって、または実装間やロケール間で、異なることがあります。
すべてのオブジェクトが、任意の文字で構成される名前を持つことができるわけではありません。次のオブジェクトは、ASCII 文字から構成される名前にする必要があります。
- ユーザー名、グループ名、およびパスワード
- システム名
- プリンタおよび特殊デバイスの名前
- 端末の名前 (/dev/tty*)
- プロセス ID 番号
- メッセージキュー、セマフォー、および共有メモリーラベル。
- 以降は、ISO Latin-1 文字または EUC 文字で構成する必要があります。
  - ファイル名
  - ディレクトリ名
  - コマンド名
  - シェルの変数および環境変数名
  - ファイルシステムへのマウントポイント
  - NIS キー名およびドメイン名
NFS 共有ファイルの名前は、ASCII 文字で構成するようにしてください。ファイルやディレクトリの名前や内容に、ASCII 以外のコードセットの文字を使用することもできますが、ASCII コードセットのみを使用すると、ローカリゼーションに関係なくどのマシンでも NFS マウントを使用できます。CSI が有効にされているコマンドおよびユーティリティーはいずれも、2.6 でリリースされたシングルバイトおよび複数バイトのロケールを処理できます。アプリケーションが国際化サービスの完全なサポートを受けるには、動的リンクを適用する必要があります。静的にリンクされたプログラムでは、C ロケールおよび POSIX ロケールだけがサポートされます。

インタフェースの安定性

Sun は多くの場合、開発者が新しい技術をできるだけ早く評価できるようにするため、初期の段階で開発者がそれらの技術へアクセスできるようにします。残念ながら、新しい技術は変更が生じやすいため、標準化により以前のバージョンとのインタフェースの非互換性が生じることもよくあります。

リスクに対する予測を合理的に行うために、開発者は将来のリリースでインタフェースがどの程度変更される可能性があるかを知っておく必要があります。開発者がこうした予測をしやすくするため、インタフェースの安定性についての情報が、コマンド、エントリポイント、およびファイル形式に関するいくつかのマニュアルページに含まれています。

比較的安定したインタフェースについて、Sun は、将来のマイナーリリースでも引き続き確実に動作するよう努力します。このため、ほぼすべてのアプリケーションで安全に使用できます。「標準」および「安定」インタフェースにのみ依存するアプリケーションは、確実に将来のマイナーリリースでも正常に機能し続けます (ただし過去のメジャーリリースで機能するとは限らない)。

比較的安定していないインタフェースについては、実験と試作が可能ですが、将来のマイナーリリースで互換性のない変更がなされたり、削除されたり、代替のインタフェースと置き換えられたりする可能性を理解したうえで使用するようにしてください。

Sun がドキュメント化しない「インタフェース」(たとえば、ほとんどのカーネルデータ構造およびシステムヘッダーファイルの一部のシンボル) は、実装によるアーティファクトである場合があります。そのような内部インタフェースは、互換性のない変更がなされたり削除されたりする場合があり、また、通常、リリースノートでそのような変更について言及されることはありません。

リリースレベル

互換性について検討する助けとして、製品には名前とともにリリースレベルが付与されています。各リリースレベルには、低いレベルに適合する変更も含まれます。

リリース	バージョン	重要度
メジャー	x.0	重要な機能が追加され、異なる (場合によっては非互換の) 標準リビジョンに準拠していると考えられます。低い確率で、標準インタフェースまたは安定インタフェースが、変更、削除、または置換される場合もあります。製品の初期リリースは通常 1.0 です。
マイナー	x.y	x.0 または以前のリリース (y!=0) と比較すると、次を含む場合があります。重要でない機能の追加、互換性のある標準インタフェースおよび安定インタフェース、場合によっては非互換の開発中インタフェース、または、非互換である可能性の高い不安定インタフェース。
マイクロ	x.y.z	以前のリリース (z!=0) とのインタフェース互換性確保が意図されますが、バグフィックス、パフォーマンス拡張、およびハードウェアサポートが追加される場合もあります。

分類

次の表は、安定性レベルの分類とリリースレベルとの関係をまとめたものです。最初の列は安定性レベルです。2 番目の列は互換性のない変更のリリースレベルを、3 番目の列はその他のコメントを表します。個別の分類に関する完全な考察については、以降の該当するサブセクションを参照してください。

安定性	リリース	コメント
標準 (Standard)	メジャー (x.0)	実際またはデファクト。
安定 (Stable)	メジャー (x.0)	非互換性は例外的です。
開発中 (Evolving)	マイナー (x.y)	非互換の場合は移行に関する助言が提供されることがあります。
不安定 (Unstable)	マイナー (x.y)	実験的または暫定的。非互換は一般的です。
外部 (External)	マイクロ (x.y.z)	Sun の管轄外。リリース内での非互換は一般的です。
廃止 (Obsolete)	マイナー (x.y)	推奨されないインタフェース。将来のマイナーリリースで削除予定。

このマニュアルページで説明されているインタフェースの安定性レベルの分類は、特に明記しない限り、ソースインタフェースとバイナリインタフェースの両方に適用されます。すべての安定性レベルの分類は公開されていますが、非公開 (Private) 分類だけは例外です。ドキュメント化されたインタフェース (マニュアルページにドキュメント化されたもの) の安定性レベルは、明示されていない限り特定されていません。ドキュメント化されていないインタフェースの安定性レベルは、暗黙的に非公開です。

Solaris 製品のコンポーネントのマニュアル以外のマニュアルが存在しても、Solaris 製品により提供されるインタフェースについて、いずれかの安定性レベルが暗示されているとみなすべきではありません。安定性レベルに関する唯一の情報源は、Solaris のマニュアルページです。

標準[: [organization_name,] standard_name, version]

ドキュメント化されたインタフェースは、リストにある標準を満たしています。標準が指定されていない場合、インタフェースは複数の標準によって定義されます。これは通常、C 言語 (ISO/IEC または K&R による定義)、SVID 3 および関連する ABI (AT&T による定義)、POSIX 標準 (IEEE および ISO/IEC による定義)、および単一 UNIX 仕様 (Single UNIX Specifications; The Open Group による定義) から構築された階層です。これらの標準の完全なリストは、standards(5) を参照してください。

これらのインタフェースの大部分は正式な標準によって定義され、規格開発組織によって制御されています。変更は通常、その標準での承認された変更にしたがってなされます。この安定性レベルは、(正式な標準ではなく) 業界標準として使用されているインタフェースにも適用されます。

サポートは、標準の指定したバージョンに対してのみ提供され、以降のバージョンに対するサポートは保証されません。規格開発組織が、Sun がサポートすると決定した標準インタフェースに対して上位互換のない変更を承認した場合、Sun は互換性および移行に関する戦略を発表します。

移植性のあるアプリケーションを作成するプログラマは、標準インタフェースのマニュアルページの説明ではなく、アプリケーションが準拠しようとする標準または仕様に存在するインタフェースの説明を利用するべきです。標準または仕様に複数の実装の選択肢がある場合、通常、マニュアルページには Sun による実装だけが説明されています。マニュアルページには、Sun が提供する標準インタフェースの基本定義に対する互換性のある拡張についても説明されています。

安定

安定インタフェースは、Sun の制御下にある完成されたインタフェースです。Sun はこれらのインタフェースに対する変更が、特にマイナーまたはマイクロリリースで、上位非互換にならないように努めます。

安定インタフェースに対するサポートを中止しなければならない場合、Sun は通知を行うように努め、安定性レベルは廃止に変更されます。

開発中

開発中インタフェースは、最終的には標準または安定となる可能性がありますが、まだ移行中のものです。

Sun は、開発の過程で以前のバージョンとの互換性が確保されるよう、相応の努力を払います。上位非互換の変更が必要になったとき、変更はマイナーおよびメジャーリリースで生じるようにし、マイクロリリースでは可能な限りそのような変更を避けるようにします。そのような変更が必要な場合、影響のあるリリースのリリースノートにドキュメント化され、可能ならば Sun はバイナリ互換およびソース開発継続のための移行支援を提供します。

外部

外部インタフェースは、Sun 以外の団体によって制御されています。Sun は、このようなインタフェースを、任意のリリースの一部として自由に提供できますが、制御団体から入手できるインタフェースのバージョンが更新されて互換性を失う場合があります。この分類は一般的に、公開されている「フリーウェア」およびこれに類するオブジェクトに当てはまります。

外部インタフェースの場合、Sun は 2 つのリリース間でのソースまたはバイナリのどちらの互換性に関しても保証しません。これらのインタフェースに基づくアプリケーションは、外部インタフェースを含むパッチを含め、将来のリリースでは動作しなくなる場合があります。

不安定

不安定インタフェースは、開発者が新しいまたは急速に変化している技術を利用できるようにするため、またはより安定したソリューションが将来予期できる場合に、問題に対する暫定的なソリューションとして提供されます。

不安定インタフェースの場合、Sun は 2 つのマイナーリリース間でのソースまたはバイナリのどちらの互換性に関しても保証しません。これらのインタフェースに基づいて開発されるアプリケーションは、将来のマイナーリリースで動作しなくなる場合があります。

廃止: event のあとで除去予定

廃止インタフェースは現在のリリースではサポートされていますが、将来の (マイナー) リリースでは削除される予定です。インタフェースのサポートが中止されるとき、Sun はサポートを中止する前に発表を行うよう努めます。廃止インタフェースを使用すると、警告メッセージが表示される場合があります。

非公開

非公開インタフェースは、提供元のコンポーネント (または製品) 自体による使用のみが意図されたインタフェースです。それでも非公開インタフェースは、ほかのコンポーネントから見えたりアクセスできたりする場合があります。ほかのコンポーネントの非公開インタフェースを使用することは安定性の大きなリスクが伴うため、そのような使用は明示的にサポートされていません。Sun Microsystems によって提供されていないコンポーネントは、非公開インタフェースを使用するべきではありません。

ほとんどの非公開インタフェースはドキュメント化されていません。非公開インタフェースがドキュメント化されているのは例外的です。非公開インタフェースがドキュメント化される理由として、公開安定性レベルのいずれかに再分類される予定がある、普及度が非常に高い、などが挙げられます。

MT レベル

ライブラリは、複数のスレッドをサポートする能力に応じてカテゴリに分類されます。複数または異なるレベルの関数を含むマニュアルページでは、「注意事項」または「使用法」のセクションでこの点が説明されています。

安全

安全はマルチスレッドのアプリケーションから呼び出し可能なコードの属性です。安全インタフェースまたは安全コードセグメントへの呼び出しにより、複数のスレッドによって呼び出された場合でも結果が有効になります。よく見過ごされる点ですが、この安全インタフェースまたは安全コードセグメントの結果は、すべてのスレッドにグローバルな影響を及ぼす可能性があります。たとえば、あるスレッドのファイルを開いたり閉じたりするアクションは、プロセス内の他のすべてのスレッドから表示可能です。マルチスレッドのアプリケーションには、これらのインタフェースを安全な方法で使用する責任があり、これはインタフェースが安全かどうかとは異なります。たとえば、アプリケーション内の他のスレッドによってまだ使用中のファイルを閉じるマルチスレッドのアプリケーションは、close(2) インタフェースを安全に使用していません。

安全ではない

安全ではないライブラリには、保護されていないグローバルおよび静的なデータが含まれています。ライブラリ内で一度に 1 つのスレッドだけが実行されるようアプリケーションで取り決めない限り、このライブラリの使用は安全ではありません。安全ではないライブラリには安全な関数が含まれている場合がありますが、ほとんどのライブラリの関数は呼び出すのが安全ではありません。安全ではない一部の関数は、MT-安全である再入可能な対象を持ちます。再入可能な関数には、関数名に _r のサフィックスが付いています。

MT-安全

MT-安全ライブラリは、マルチスレッドのアクセスに対する準備が整っています。ロックによってグローバルおよび静的なデータを保護し、適度な量の並行性を実現しています。安全に使用できるライブラリも、MT-安全であるとは限りません。たとえば、ライブラリ全体をモニターで囲むとライブラリは安全になりますが、並行性をサポートしないため MT-安全とはみなされません。MT-安全ライブラリは適度な量の並行性を許容する必要があります。(この定義の目的は、ライブラリが安全であるとされる際に、その意味するものを明確にすることです。安全なライブラリの定義では、ライブラリが並行性をサポートするかどうかは示しません。MT-安全の定義では、ライブラリが安全で、ある程度の並行性をサポートすることを明確にしています。つまり安全の定義では、シングルスレッドを意味する場合も、任意の程度のマルチスレッドを意味する場合もあります。)

非同期シグナル安全

非同期シグナル安全とは、シグナルハンドラから安全に呼び出すことのできる特定のライブラリ関数のことです。非同期シグナル安全関数を実行するスレッドは、シグナルによって割り込まれた場合に、自分自身でデッドロックすることはありません。シグナルは、ロックを取得する MT-安全関数にとってのみ問題になります。

非同期シグナル安全関数は、MT-安全でもあります。非同期シグナル安全関数でロックが取得されると、シグナルは無効になります。これらのシグナルは、同じロックを取得する可能性のあるシグナルハンドラが呼び出されないようにします。

MT-安全の例外

例外の説明については、このページの「注意事項」または「使用法」のセクションを参照してください。

安全の例外

例外の説明については、このページの「注意事項」または「使用法」のセクションを参照してください。

Fork-安全

fork(2) 関数は、その関数を呼び出したスレッドだけを子プロセスに複製します。fork1(2) 関数は、以前の関数との互換性のために存在しており、 fork() と同義です。fork() が呼び出されたとき、fork を実行しているスレッド以外のスレッドがロックを保持していた場合、ロックは子プロセスに引き続き保持されますが、所有者であるスレッドは複製されないため、ロックには所有者がいないことになります。ロックの取得を試みる関数を子が呼び出すと、デッドロックが発生します。

fork() が呼び出されるとき、Fork-安全ライブラリはその内部ロックすべてが fork を実行するスレッドによってのみ保持されるようにします。これは通常、ライブラリの初期化時に呼び出される pthread_atfork(3C) により実現されます。

forkall(2) 関数は、まれなケースとして、fork を実行するときにプロセスがそのすべてのスレッドを複製する必要がある場合にその機能を提供します。forkall() が呼び出されたときに、pthread_atfork() アクションは実行されません。forkall() を呼び出すことに関連する危険が存在します。プロセス内のスレッドで入出力操作を実行中に、別のスレッドが forkall() を呼び出すと、同じ入出力操作が親プロセスと子プロセスの両方で行われ続け、結果としてデータが破壊される場合があります。このような競合状態に関する理由から、forkall() の使用は推奨されていません。

Solaris 10 よりも前のすべての Solaris リリースでは、fork() の動作はアプリケーションが -lpthread (POSIX スレッド、standards(5) を参照) とリンクしているかどうかに依存していました。-lpthread とリンクされている場合、fork() は fork1() と同じように動作し、リンクしていない場合は forkall() と同じように動作していました。fork() の動作に関する混乱を避けるため、アプリケーションは状況に応じてfork1() または forkall() を指定できるようになりました。

取り消し安全性

マルチスレッドアプリケーションが pthread_cancel(3C) を使用してスレッドを取り消し (すなわち終了) する場合、対象となるスレッドがロックまたは割り当てられたメモリーなどのリソースを保持したまま終了する場合があります。スレッドにリソースを適切に解放する適切な取り消しクリーンアップハンドラがインストールされていない場合 (pthread_cancel(3C) を参照)、アプリケーションは「取り消し非安全」つまり取り消しに関して安全ではないことになります。このように安全でないと、取り消されたスレッドのロックが解放されないため、またはリソースリーク (たとえばスレッドの取り消し時にメモリーが解放されないなど) のために、デッドロックが生じる可能性があります。pthread_cancel(3C) を使用するアプリケーションはすべて、取り消し安全環境で実行されるべきです。取り消しポイントを持ち、ロックなどのリソースを取得したり動的にメモリーを割り当てたりするライブラリは、これらのライブラリにリンクされたアプリケーションの取り消し非安全性の一因となります。これにより、マルチスレッドプログラムでのライブラリの安全性に別のレベルが導入されることになります。取り消し安全性です。取り消し安全性には、2 つのサブカテゴリがあります。遅延取り消し安全性、および非同期取り消し安全性です。取り消しのタイプが PTHREAD_CANCEL_DEFERRED であるスレッドが取り消し安全であるとき、アプリケーションは遅延取り消し安全であるとみなされます。取り消しのタイプが PTHREAD_CANCEL_ASYNCHRONOUS であるスレッドが、取り消し安全であるとき、アプリケーションは非同期取り消し安全であるとみなされます。非同期取り消しタイプはどこでも取り消しができる一方、遅延取り消しタイプのスレッドは十分に定義された取り消しポイントによってのみ取り消しができるため、非同期取り消し安全性よりも遅延取り消し安全性の方が目的を達成するのが容易です。すべてのスレッドはデフォルトで遅延取り消しタイプを含んで作成されるため、非同期の取り消しを安全に行うことを心配する必要はないかもしれません。ほとんどのアプリケーションおよびライブラリは、常に非同期取り消し非安全であるものと想定されています。非同期取り消し安全であるアプリケーションは、定義上は、遅延取り消し安全でもあります。