From 4b45ae0f47d9e30589a4143de94d376e8e58d7df Mon Sep 17 00:00:00 2001 From: Gabriel Corona Date: Wed, 13 Jul 2016 14:28:20 +0200 Subject: [PATCH 1/1] [doc] TODO --- doc/doxygen/community_giveback.doc | 71 ++++++++++++++++++++++++++++++ 1 file changed, 71 insertions(+) diff --git a/doc/doxygen/community_giveback.doc b/doc/doxygen/community_giveback.doc index 94c276df57..a67ccae5a0 100644 --- a/doc/doxygen/community_giveback.doc +++ b/doc/doxygen/community_giveback.doc @@ -103,4 +103,75 @@ SimGrid, we'd love helping you gaining visibility by listing it on our Contrib section. +@section contributing_todo Enchancements + +If you want to want to start working on the SimGrid codebase, here are a few +ideas of things that could be done to improved the current code (not all of them +are easy, though): + +@subsection contributing_todo_cxxification Migration to C++ + +The code is being migrated to C++ but a large part is still C (or C++ with + idioms). It would be valuable to replace C idioms with C++ ones: + + - replace XBT structures with C++ containers; + + - replace `char*` with `std::string`; + + - use RAII (`std::unique_ptr`, etc.) instead of explicit `malloc/free` or + `new/delete`. + +@subsection contributing_todo_exceptions Migration to C++ + +SimGrid used to implement exceptions in C. This has been replaced with C++ +exceptions but some bits of the C exceptions are still remaining: + + - `xbt_ex` was the type of C exceptions. It is now a standard C++ exception. + We might want to remove this and use a more idiomatic C++ solution. + `std::system_error` might be used for some error categories. + + - The C API currently throws exceptions exceptions. Throwing exceptions out + of C API is not very friendly. C code does not expect them, cannot catch + them and cannot handle resource management properly with exceptions. + We should clearly separate the C++ API and the C API and catch all exceptions + before they get ouf of C APIs. + +@subsection contributing_todo_futures Additions to the futures + + - Some features are missing in the Maestro future implementation + (`simgrid::simix::Future`, `simgrid::simix::Promise`) + could be extended to support additional features: + `when_any`, `shared_future`, etc. + + - The corresponding feature might then be implemented in the user process + futures. + + - We might need to provide the option to cancel a pending operation. This + might be achieved by defining some `Action` or `Operation` class with an + API compatible with `Future` (and convertiable to it) but with an + additional `.cancel()` method. + +@subsection contributing_todo_simcalls Simcalls cleanup + + - Remove simcalls by using the generic ones. One issue with this is that we + didn't devise a good way to deal with generic simcalls in the model-checker + yet. + +@subsection contributing_todo_mc Model-checker + + - Find a good solution to handle generic simcalls in the model-checker. + + - Define a clear interface to be used by model-checking algorithms. The + `Session` class in intended to expose this interface but it is not a thing + yet. + + - Rewrite the different algorithms as implementations of the `Checker` class + using the `Session` inteface. + + - Currently a lot of informations the model-checker reads many informations + about the model-checked process by `process_vm_readv()`-ing brutally the + data structure leading to some horrible code such as walking a swag from + another process. It would be nice to have a sane way for the model-checker + to expose the relevant information to the model-checker. + */ \ No newline at end of file -- 2.20.1