Logo AND Algorithmique Numérique Distribuée

Public GIT Repository
Remove Java bindings. They are not updated since maybe 10 years
[simgrid.git] / doc / doxygen / FAQ.doc
index 5b902f4..1f95d4f 100644 (file)
@@ -9,33 +9,15 @@ This document is the FAQ of the MSG interface. Some entries are a bit aging and
 You are at the right place... To understand what you can do or
 cannot do with SimGrid, you should read the
 <a href="https://simgrid.org/tutorials.html">tutorial
-slides</a> from the SimGrid's website. You may find more uptodate
+slides</a> from the SimGrid's website. You may find more up-to-date
 material on the
 <a href="http://people.irisa.fr/Martin.Quinson/blog/SimGrid/">blog of
-Martin Quinson</a>. 
+Martin Quinson</a>.
 
 Another great source of inspiration can be found in the @ref s4u_examples.
 
 If you are stuck at any point and if this FAQ cannot help you, please drop us a
-mail to the user mailing list: <simgrid-user@lists.gforge.inria.fr>.
-
-@subsection faq_interfaces What is the difference between MSG and SimDag? Do they serve the same purpose?
-
-It depend on how you define "purpose", I guess ;)
-
-They all allow you to build a prototype of application which you can run
-within the simulator afterward. They all share the same simulation kernel,
-which is the core of the SimGrid project. They differ by the way you express
-your application.
-
-With SimDag, you express your code as a collection of interdependent
-parallel tasks. So, in this model, applications can be seen as a DAG of
-tasks. This is the interface of choice for people wanting to port old
-code designed for SimGrid v1 or v2 to the framework current version.
-
-With MSG, your application is seen as a set of communicating
-processes, exchanging data by the way of messages and performing
-computation on their own.
+mail to the user mailing list: <simgrid-community@inria.fr>.
 
 @subsection faq_visualization Visualizing and analyzing the results
 
@@ -50,19 +32,6 @@ filter (e.g. with bash):
 
 We also have a more graphical output. Have a look at section @ref options_tracing.
 
-@subsection faq_C Argh! Do I really have to code in C?
-
-We provide Java bindings of the MSG interface, which is the main
-SimGrid user API.
-
-Moreover 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).
-
-For now, we do not feel a real demand for any other language. But if
-you think there is one, please speak up!
-
 @section faq_howto Feature related questions
 
 @subsection faq_MIA "Could you please add (your favorite feature here) to SimGrid?"
@@ -109,20 +78,20 @@ this in the real realm.
 If you really need to synchronize your processes (because it's what
 you are studying or to create an atomic section that spans over
 several simcalls), you obviously cannot use regular synchronization
-mechanisms (pthread_mutexes in C or the synchronized keyword in Java).
+mechanisms (pthread_mutexes in C).
 This is because the SimGrid kernel locks all processes and unlock them
 one after the other when they are supposed to run, until they give the
-control back in their simcall. If one of them gets locked by the OS 
+control back in their simcall. If one of them gets locked by the OS
 before returning the control to the kernel, that's definitively a
 deadlock.
 
 Instead, you should use the synchronization mechanism provided by the
 simulation kernel. This could with a SimGrid mutex, a SimGrid
 condition variables or a SimGrid semaphore, as described in @ref
-msg_synchro (in Java, only semaphores are available). But actually,
+msg_synchro. But actually,
 many synchronization patterns can be encoded with communication on
 mailboxes. Typically, if you need one process to notify another one,
-you could use a condition variable or a semphore, but sending a
+you could use a condition variable or a semaphore, but sending a
 message to a specific mailbox does the trick in most cases.
 
 @subsubsection faq_MIA_communication_time How can I get the *real* communication time?
@@ -140,7 +109,7 @@ int sender()
   m_task_t task = MSG_task_create("Task", task_comp_size, task_comm_size,
                                   calloc(1,sizeof(double)));
   *((double*) task->data) = MSG_get_clock();
-  MSG_task_put(task, slaves[i % slaves_count], PORT_22);
+  MSG_task_put(task, workers[i % workers_count], PORT_22);
   XBT_INFO("Send completed");
   return 0;
 }
@@ -231,50 +200,8 @@ their own batch schedulers. Vincent Garonne wrote one during his PhD
 and put his code in the contrib directory of our SVN so that other can
 keep working on it. You may find inspiring ideas in it.
 
-@subsubsection faq_MIA_checkpointing I need a checkpointing thing
-
-Actually, it depends on whether you want to checkpoint the simulation, or to
-simulate checkpoints.
-
-The first one could help if your simulation is a long standing process you
-want to keep running even on hardware issues. It could also help to
-<i>rewind</i> the simulation by jumping sometimes on an old checkpoint to
-cancel recent calculations.@n
-Unfortunately, such thing will probably never exist in SG. One would have to
-duplicate all data structures because doing a rewind at the simulator level
-is very very hard (not talking about the malloc free operations that might
-have been done in between). Instead, you may be interested in the Libckpt
-library (http://www.cs.utk.edu/~plank/plank/www/libckpt.html). This is the
-checkpointing solution used in the condor project, for example. It makes it
-easy to create checkpoints (at the OS level, creating something like core
-files), and rerunning them on need.
-
-If you want to simulate checkpoints instead, it means that you want the
-state of an executing task (in particular, the progress made towards
-completion) to be saved somewhere.  So if a host (and the task executing on
-it) fails (cf. #MSG_HOST_FAILURE), then the task can be restarted
-from the last checkpoint.@n
-
-Actually, such a thing does not exist in SimGrid either, but it's just
-because we don't think it is fundamental and it may be done in the user code
-at relatively low cost. You could for example use a watcher that
-periodically get the remaining amount of things to do (using
-MSG_task_get_remaining_computation()), or fragment the task in smaller
-subtasks.
-
 @subsection faq_platform Platform building and Dynamic resources
 
-@subsubsection faq_platform_example Where can I find SimGrid platform files?
-
-There are several little examples in the archive, in the examples/platforms
-directory. From time to time, we are asked for other files, but we
-don't have much at hand right now.
-
-You should refer to the Platform Description Archive
-(http://pda.gforge.inria.fr) project to see the other platform file we
-have available, as well as the Simulacrum simulator, meant to generate
-SimGrid platforms using all classical generation algorithms.
-
 @subsubsection faq_platform_synthetic Generating synthetic but realistic platforms
 
 Another possibility to get a platform file is to generate synthetic
@@ -299,102 +226,6 @@ assessed. Please keep this fact in mind when using it.
 
 @section faq_troubleshooting Troubleshooting
 
-@subsection faq_trouble_changelog The feature X stopped to work after my last update 
-
-I guess that you want to read the ChangeLog file, that always contains
-all the information that could be important to the users during the
-upgrade. Actually, you may want to read it (alongside with the NEWS
-file that highlights the most important changes) even before you
-upgrade your copy of SimGrid, too.
-
-We do our best to maintain the backward compatibility, but we
-sometimes have to fix the things that are too broken. If we happen to
-kill a feature that you were using, we are sorry. We think that you
-should update to the new way of doing things, but if you can't afford
-it, that's ok. Just stick to the last version that were working for
-you, and have a pleasant day.
-
-@subsection faq_trouble_compil User code compilation problems
-
-@subsubsection faq_trouble_err_logcat "gcc: _simgrid_this_log_category_does_not_exist__??? undeclared (first use in this function)"
-
-This is because you are using the log mechanism, but you didn't created
-any default category in this file. You should refer to @ref XBT_log
-for all the details, but you simply forgot to call one of
-XBT_LOG_NEW_DEFAULT_CATEGORY() or XBT_LOG_NEW_DEFAULT_SUBCATEGORY().
-
-@subsubsection faq_trouble_pthreadstatic "gcc: undefined reference to pthread_key_create"
-
-This indicates that one of the library SimGrid depends on (libpthread
-here) was missing on the linking command line. Dependencies of
-libsimgrid are expressed directly in the dynamic library, so it's
-quite impossible that you see this message when doing dynamic linking.
-
-If you compile your code statically (and if you use a pthread version
-of SimGrid), you must absolutely
-specify <tt>-lpthread</tt> on the linker command line. As usual, this should
-come after <tt>-lsimgrid</tt> on this command line.
-
-@subsection faq_trouble_errors Runtime error messages
-
-@subsubsection faq_trouble_errors_big_fat_warning I'm told that my XML files are too old.
-
-The format of the XML platform description files is sometimes
-improved. For example, we decided to change the units used in SimGrid
-from MBytes, MFlops and seconds to Bytes, Flops and seconds to ease
-people exchanging small messages. We also reworked the route
-descriptions to allow more compact descriptions.
-
-That is why the XML files are versionned using the 'version' attribute
-of the root tag. Currently, it should read:
-@verbatim
-  <platform version="4">
-@endverbatim
-
-If your files are too old, you can use the simgrid_update_xml.pl
-script which can be found in the tools directory of the archive.
-
-@subsection faq_trouble_debug Debugging SMPI applications
-
-In order to debug SMPI programs, you can use the following options:
-
-- <b>-wrapper 'gdb --args'</b>: this option is used to use a wrapper
-  in order to call the SMPI process. Good candidates for this options
-  are "gdb --args", "valgrind", "rr record", "strace", etc;
-
-- <b>-foreground</b>: this options gives the debugger access to the terminal
-  which is needed in order to use an interactive debugger.
-
-Both options are needed in order to run the SMPI process under GDB.
-
-@subsection faq_trouble_valgrind Valgrind-related and other debugger issues
-
-If you don't, you really should use valgrind to debug your code, it's
-almost magic.
-
-@subsubsection faq_trouble_backtraces Truncated backtraces
-
-When debugging SimGrid, it's easier to pass the
---disable-compiler-optimization flag to the configure if valgrind or
-gdb get fooled by the optimization done by the compiler. But you
-should remove these flag when everything works before going in
-production (before launching your 1252135 experiments), or everything
-will run only one half of the true SimGrid potential.
-
-@subsection faq_deadlock There is a deadlock in my code!!!
-
-Unfortunately, we cannot debug every code written in SimGrid.  We
-furthermore believe that the framework provides ways enough
-information to debug such information yourself. If the textual output
-is not enough, Make sure to check the @ref faq_visualization FAQ entry to see
-how to get a graphical one.
-
-Now, if you come up with a really simple example that deadlocks and
-you're absolutely convinced that it should not, you can ask on the
-list. Just be aware that you'll be severely punished if the mistake is
-on your side... We have plenty of FAQ entries to redact and new
-features to implement for the impenitents! ;)
-
 @subsection faq_surf_network_latency I get weird timings when I play with the latencies.
 
 OK, first of all, remember that units should be Bytes, Flops and
@@ -436,23 +267,4 @@ that may make your result be unexpected. For example, two flows
 competing on a saturated link receive an amount of bandwidth inversely
 proportional to their round trip time.
 
-@subsection faq_bugrepport So I've found a bug in SimGrid. How to report it?
-
-We do our best to make sure to hammer away any bugs of SimGrid, but this is
-still an academic project so please be patient if/when you find bugs in it.
-If you do, the best solution is to drop an email either on the simgrid-user
-or the simgrid-devel mailing list and explain us about the issue.  You can
-also decide to open a formal bug report using the
-<a href="https://gforge.inria.fr/tracker/?atid=165&group_id=12&func=browse">relevant
-interface</a>. You need to login on the server to get the ability to submit
-bugs.
-
-We will do our best to solve any problem repported, but you need to help us
-finding the issue. Just telling "it segfault" isn't enough. Telling "It
-segfaults when running the attached simulator" doesn't really help either.
-You may find the following article interesting to see how to repport
-informative bug repports:
-http://www.chiark.greenend.org.uk/~sgtatham/bugs.html (it is not SimGrid
-specific at all, but it's full of good advices).
-
 */