+++ /dev/null
-<!-- ##### SECTION Title ##### -->
-SG
-
-<!-- ##### SECTION Short_Description ##### -->
-Implementation of GRAS on top of the simulator.
-
-<!-- ##### SECTION Long_Description ##### -->
-<para>
- SimGrid was designed to ease the comparison of algorithms and
- heuristics. That way, a lot of complicated notion from the system layer
- were volontary left off. For example, migrating a process from an host to
- another is as easy as: MSG_process_change_host(process, new_host).
-</para>
-
-<para>
- No need to tell that performing this operation on real platform is really
- harder. This simplification is a very good thing when you want to rapidly
- prototype code, but makes things somehow more complicated in GRAS since
- we want to have a realistic API, since it have to be implemented in
- reality also.
-</para>
-
-<para>
- The best example of complexity in GRAS_SG induced by simplicity in
- SimGrid is the sockets handling. There is no "socket" in SG, but only
- m_channel_t. In contrary to sockets from RL, no special treatment is
- needed for a process before writing or reading on/from a channel. So, a
- given channel can be pooled by more than one process. Likewise, you can
- send data to a channel that nobody is actually listening to.
-</para>
-
-<para>
- The SG implementation of GRAS repport as an error the fact that nobody is
- listening to the socket when trying to open a socket, or send stuff using
- a previously openned socket. That way, the SG version can be used to
- debug all syncronization issues. For that, we store mainly the PID of
- both the sender and the receiver in the socket structure, and then
- resolve PID->process at the lastest moment. This search is a bit
- expensive, but as long as there is no real garbage collection in SG, with
- the information "dead process" within the structure, it's the only
- solution to make sure that we won't dereference pointers to an old freed
- structure when the process on the other side of the structure did finish
- since the creation of the socket.
-</para>
-
-<para>
- As said in the overview, the processes can declare to hear on several
- sockets, but all incoming messages are handled by the same loop. So, we
- can use only one channel per process, and use a table on each host to
- determine to which process a message should be delivered depending on the
- socket number provided by the sender.
-</para>
-
-<!-- ##### SECTION See_Also ##### -->
-<para>
-RL, the implementation suited for real life.
-</para>
-
-<!--
-Local variables:
-sgml-parent-document:\.\./gras-docs\.sgml
-sgml-omittag:t
-sgml-shorttag:t
-sgml-namecase-general:t
-sgml-general-insert-case:lower
-sgml-minimize-attributes:nil
-sgml-always-quote-attributes:t
-sgml-indent-step:2
-sgml-indent-data:nil
-sgml-exposed-tags:nil
-sgml-local-catalogs:nil
-sgml-local-ecat-files:nil
-End:
--->
-
