From 8d8da3b6e2ddb285529f576140cce72b092aff9b Mon Sep 17 00:00:00 2001 From: =?utf8?q?Christophe=20Thi=C3=A9ry?= Date: Fri, 29 Jul 2011 17:29:19 +0200 Subject: [PATCH 1/1] Add a TODO file with my ideas to make splay work. --- examples/lua/SimSplay/TODO | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) create mode 100644 examples/lua/SimSplay/TODO diff --git a/examples/lua/SimSplay/TODO b/examples/lua/SimSplay/TODO new file mode 100644 index 0000000000..42dcb7f73b --- /dev/null +++ b/examples/lua/SimSplay/TODO @@ -0,0 +1,26 @@ +-------------------------------------------- +A few notes abouts what I would like to do +to make Splay applications work with SimGrid +-------------------------------------------- + +Create an executable "simsplay" that runs a Splay Lua script +with SimGrid. + +Ideally, its usage would be: + +simsplay platform_file.{xml|lua} deployment_file.{xml|lua} splay_script.lua [simgrid_options...] + +I'm not sure about the format of the platform and deployment files yet. +We could accept both XML and Lua files, since their is a great Lua API to +describe platforms, or only the XML ones. + +The simsplay executable (which is compiled C) would initialize SimGrid, create +the environment, and for each simulated process, create a new lua_State* +object that runs the Lua script provided by the user (splay_script.lua in the +example above). + +The current Lua API of SimGrid (3.6) uses Lua coroutines (i.e. sequential, +lightweight threads) to simulate processes in a single, shared Lua state. +However, in Splay, the Lua global values must not be shared between simulated +processes: this is why we need distinct Lua states. + -- 2.20.1