G-WAN はきちんとした Web サーバーです。「C スクリプト」の概念に基づいています。
AC スクリプトは、Web サーバーによってコンパイルされ、保護されたメモリにロードされる単純な C ソース コードです。サーブレットへのリクエストが行われると、Web サーバーによって呼び出されます。サーブレットは、C コンパイラによってコンパイルされるため、通常の C プログラムのコンパイルと同じくらい高速です。ただし、たとえば CGI や FastCGI に対する C スクリプトの利点は、コンパイルされたプログラムが Web サーバーと同じメモリ空間にあることです。これにより、通信のオーバーヘッドが削減されます (CGI の場合は要求ごとにプロセスを作成するか、FastCGI の場合はソケットを作成することによって)。
Web サーバーは選択/ポーリング手法を使用しています: ノンブロッキング I/O。しかし、それにはきちんとしたことがあります。すべてのプログラムは、ブロッキング I/O を使用しているかのように作成できます。Web サーバー自体が各 C スクリプトをコンパイルするため、非ブロッキング I/O を使用するようにプログラムを変換できます。この時点で、それ自体をサードパーティ ライブラリ (データベース アクセスなど) にリンクすることができ、スレッド/プロセス コンテキストの切り替えがない非ブロッキング I/O の性質を引き続き利用できます。
C スクリプトをプログラミングするために提供されるツールは、たとえば、キャッシングやセーフ バッファです。次の (この記事の執筆時点ではまだリリースされていない) バージョンには、Key-Value ストアも含まれます。
パフォーマンスに関して: 他の Web サーバーよりも優れていることを示すベンチマークがいくつかありますが、私はこれらを信頼していません。CPU を集中的に使用する小規模なプログラムを C と、たとえば PHP で作成してみてください。G-WAN で C スクリプトを実行し、Apache で PHP スクリプトを実行して、自分でベンチマークを実行します。
他にもありますが、それはこの質問の範囲外です。
G-WAN のいくつかの欠点は、開発者が 1 人しかいないことです。ただし、質問できるフォーラムがあります。
使いやすさは、C のスキルによって制限されます。ただし、提供される API は単純です。まだいくつかの矛盾と (私の意見では) 見苦しい部分がありますが、それは問題ではありません。より深刻な問題は、各バージョンが後方互換性を保証されておらず、書き直さなければならない場合があることです。
安全を確保したい場合: C のプラットフォーム非依存性を利用する: コードを (高速) CGI プログラムにコンパイルし、G-WAN で使用できるようにします。G-WAN が失敗する可能性があります。いつでも Apache の (Fast) CGI にフォールバックできます ( API については、http://www.fastcgi.com/ を参照してください) 。