+\subsection faq_postmortem_analysis Online/postmortem analysis
+
+Vizualization with Paje can be seen as a kind of postmortem
+analysis. However, as soon as you start playing with big simulations,
+you'll realize that processing such output is kind of tricky. There is
+so much generic informations that it is hard to find the information
+you are looking for.
+
+As a matter of fact, loging really depends on simulations (e.g. what
+kind of events is important...). That is why we do not propose a big
+dump of your whole simulation (it would slow everything down) but give
+you neat tools to structure you logs. Have a look at \ref XBT_log. In
+fact, rather than a post-mortem analysis, you may want to do it on the
+fly. The process you are running can do whatever you want. Have you
+thought about adding a global structure where you directly compute the
+informations that are really important rather than writing everything
+down and then processing huge files ?
+
+\subsection faq_C Argh! Do I really have to code in C ?
+
+Up until now, there is no binding for other languages. If you use C++,
+you should be able to use the SimGrid library as a standard C library
+and everything should work fine (simply <i>link</i> against this
+library; recompiling SimGrid with a C++ compiler won't work and it
+wouldn't help if you could).
+
+In fact, the bindings needed to allow one to use SimGrid from Perl,
+Python, Java, etc. are double-layered. The first layer would allow
+you to call for example the MSG_task_get_name(task) function while
+what you really want is a proper object wrapping allowing you to call
+task->name(). That's the purpose of the second layer. The first one
+is granted with C++ but can be done with tools like
+<a href="www.swig.org/">swig</a> for other languages like Perl, Ruby,
+Python, CAML. None of us really need the second one (which is a bit
+more demanding and cannot be automatically generated) yet and there is
+no real point in doing the first one without the second. :)
+
+As usual, you're welcome to participate.
+
+\section faq_MIA How to ....? Is there a function in the API to simply ....?
+
+Here is the deal. The whole SimGrid project (MSG, SURF, GRAS, ...) is
+meant to be kept as simple and generic as possible. We cannot add
+functions for everybody's need when these functions can easily be
+built from the ones already in the API. Most of the time, it is
+possible and when it was not possible we always have upgraded the API
+accordingly. When somebody asks us a question like "How to do that ?
+Is there a function in the API to simply do this ?", we're always glad
+to answer and help. However if we don't need this code for our own
+need, there is no chance we're going to write it... it's your job! :)
+The counterpart to our answers is that once you come up with a neat
+implementation of this feature (task duplication, RPC, thread
+synchronization, ...), you should send it to us and we will be glad to
+add it to the distribution. Thus, other people will take advantage of
+it (and we don't have to answer this question again and again ;).
+
+You'll find in this section a few "Missing In Action" features. Many
+people have asked about it and we have given hints on how to simply do
+it with MSG. Feel free to contribute...
+
+\subsection faq_MIA_examples I want some more complex examples!
+
+Many people have come to ask me a more complex example and each time,
+they have realized afterward that the basics were in the previous three
+examples.
+
+Of course they have often been needing more complex functions like
+MSG_process_suspend(), MSG_process_resume() and
+MSG_process_isSuspended() (to perform synchronization), or
+MSG_task_Iprobe() and MSG_process_sleep() (to avoid blocking
+receptions), or even MSG_process_create() (to design asynchronous
+communications or computations). But the examples are sufficient to
+start.
+
+We know. We should add some more examples, but not really some more
+complex ones... We should add some examples that illustrate some other
+functionalities (like how to simply encode asynchronous
+communications, RPC, process migrations, thread synchronization, ...)
+and we will do it when we will have a little bit more time. We have
+tried to document the examples so that they are understandable. Tell
+us if something is not clear and once again feel free to participate!
+:)
+
+\subsection faq_MIA_taskdup Missing in action: Task duplication/replication
+
+There is no task duplication in MSG. When you create a task, you can
+process it or send it somewhere else. As soon as a process has sent
+this task, he doesn't have this task anymore. It's gone. The receiver
+process has got the task. However, you could decide upon receiving to
+create a "copy" of a task but you have to handle by yourself the
+semantic associated to this "duplication".
+
+As we already told, we prefer keeping the API as simple as
+possible. This kind of feature is rather easy to implement by users
+and the semantic you associate really depends on people. Having a
+*generic* task duplication mechanism is not that trivial (in
+particular because of the data field). That is why I would recommand
+that you write it by yourself even if I can give you advice on how to
+do it.
+
+You have the following functions to get informations about a task:
+MSG_task_get_name(), MSG_task_get_compute_duration(),
+MSG_task_get_remaining_computation(), MSG_task_get_data_size(),
+and MSG_task_get_data().
+
+You could use a dictionnary (#xbt_dict_t) of dynars (#xbt_dict_t). If
+you still don't see how to do it, please come back to us...
+
+\subsection faq_MIA_asynchronous I want to do asynchronous communications.
+
+Up until now, there is no asynchronous communications in MSG. However,
+you can create as many process as you want so you should be able to do
+whatever you want... I've written a queue module to help implementing
+some asynchronous communications at low cost (creating thousands of
+process only to handle communications may be problematic in term of
+performance at some point). I'll add it in the distribution asap.
+
+\subsection faq_MIA_thread_synchronization I need to synchronize my processes
+
+You obviously cannot use pthread_mutexes of pthread_conds. The best
+thing would be to propose similar structures. Unfortunately, we
+haven't found time to do it yet. However you can try to play with
+MSG_process_suspend() and MSG_process_resume(). You can even do some
+synchronization with fake communications (using MSG_task_get(),
+MSG_task_put() and MSG_task_Iprobe()).
+
+\subsection faq_MIA_host_load Where is the get_host_load function hidden in MSG?
+
+There is no such thing because its semantic wouldn't be really
+clear. Of course, it is something about the amount of host throughput,
+but there is as many definition of "host load" as people asking for
+this function. First, you have to remember that resource availability
+may vary over time, which make any load notion harder to define.
+
+It may be instantaneous value or an average one. Moreover it may be only the
+power of the computer, or may take the background load into account, or may
+even take the currently running tasks into account. In some SURF models,
+communications have an influence on computational power. Should it be taken
+into account too?
+
+So, we decided not to include such a function into MSG and let people do it
+thereselves so that they get the value matching exactly what they mean. One
+possibility is to run active measurement as in next code snippet. It is very
+close from what you would have to do out of the simulator, and thus gives
+you information that you could also get in real settings to not hinder the
+realism of your simulation.
+
+\verbatim
+double get_host_load() {
+ m_task_t task = MSG_task_create("test", 0.001, 0, NULL);
+ double date = MSG_get_clock();