1

インターフェイス定義言語を必要とせずに、C または C++ ソース ファイルを記述して、ソース ファイル内の関数のクライアント/サーバー実装を自動的に作成することは可能ですか? 次の例を検討してください。

prog.c

int foo() {
  return 2;
}

foo.c私は2つのファイルに分割したいと思います:client.cそしてserver.c次のように:

client.c

int foo() {
  return server_foo();
}

server.c

int server_foo() {
  return 2;
}

server.cを実行しているマシンとは別のマシンで実行したいclient.cので、何らかの形式の RPC を実装する必要があります。私が調査したすべて (ONC RPC、XML RPC、Apache Thrift など) では、インターフェイス ファイルで関数プロトタイプを手動で定義する必要があります。prog.c配布されたアプリケーションのソース コードを自動的に生成できるプログラムにフィードする方法はありますか?

注: これらのプログラムを Unix システムで実行したい!

4

3 に答える 3

2

It is not possible in general (in particular because there is no general way to serialize arbitrary C data (or C++ data), like e.g. some FILE* handle or some void* pointer -e.g. obtained by dlopen(3) ..., or some C++11 instance of std::thread).

In general it is not possible: a shared memory is not the same as a collection of agents with message passing.

But we could assume that your prog.c has only functions involving easily serializable types. This is a strong hypothesis which is usually not true. (for instance, if you represent a tree, or some directed acyclic graph, using some struct-s, the C code does not know that it is a tree or a DAG and how it should be serialized; and if your data structure represents a more general graph you should know much more than its C coded types to serialize it, since its naive serialization would be infinite... because we don't know what is the shareable data...).

Also, even if all your types are serializable, you don't want in practice to distribute every function. For example, doing a remote call when computing strlen of strings does not make sense in practice: computing the strlen locally is thousands -or millions- of time faster than making a remote procedure call (even to an infinitely fast remote server, given the current networking delays; an RPC takes several milliseconds to transmit and receive data).

So you have to cleverly choose, within your prog.c, which functions you want to distribute on a remote server.

For example, if prog.c contains the following function:

// return a heap-allocated string to be free-d by caller
char* make_name(int x) {
   char buf[24];
   snprintf(buf, sizeof(buf), "NAME_%d", x);
   return strdup(buf);
}

you don't want to distribute it. Making an RPC call from it does not make any practical sense.

However, you might for instance consider customizing GCC (assuming you have a recent version e.g. 4.7 or 4.8) with your MELT extension which handle some common cases automatically.

MELT is a lisp-y domain specific language, implemented as a GCC [meta-]plugin, to extend GCC

So you could code your extension in MELT for gcc (and g++) which would process prog.c (while GCC is compiling it) and dump appropriate glue code (e.g. someprog_generated.x file for ONC RPC...), at least for those functions whose signature involve serializable types.

The issue is to define what exactly are your serializable types and how you serialize them (and what are the routines you want to distribute remotely); then you'll spend a week -or more- to code that MELT extension. Please ask on gcc-melt@googlegroups.com list for help and advices. You could consider adding your own #pragma-s and/or your own __attribute__ to guide the serialization and the remote distribution...

See also application checkpointing, message-passing and MPI wikipages...

于 2013-11-12T00:34:55.963 に答える