In article <2025Jul29.094901@mips.complang.tuwien.ac.at>,   
   Anton Ertl  wrote:   
   >Paul Rubin  writes:   
   >>Question is how to multitask on a small embedded target.  One way is the   
   >>traditional cooperative multitasker with a shared dictionary plus task   
   >>variables.   
   >>   
   >>Another way is time slicing multiple interpreters, each with its own   
   >>data dictionary (all variables are task variables).  There would be a   
   >>shared read-only dictionary for code and constants, and a mailbox scheme   
   >>for IPC.   
   >>   
   >>This question is more about shared vs non-shared than cooperative vs   
   >>preemptive.  The latter would be Erlang-style preemptive, i.e. avoiding   
   >>most locking hazards by using mailboxes instead of memory sharing.   
   >>   
   >>Does anyone do it this way?  Is the overhead substantial?   
   >   
   >Gforth is not for small embedded systems, but anyway, the development   
   >version does multi-tasking by mapping each task to a POSIX thread   
   >(within one process), with the classical USER variable mechanism for   
   >task-local variables, multiprocessing/preemption (coming from POSIX   
   >threads), and an actor-like mechanism for communicating between tasks   
   >and for synchronizing them (there are also other synchronizing   
   >mechanisms).  The messages that the actor-like mechanism delivers to   
   >the mailbox of a task are xts that the receiving task executes.  You   
   >can read about that in https://net2o.de/gforth/Multitasker.html.   
   >   
   >Concerning the idea of replicating all variables and buffers in each   
   >task, that seemed too expensive in memory for Gforth, and I expect   
   >that it is considered too expensive all the more for small embedded   
   >targets.  For Gforth we want to be able to support a huge number of   
   >tasks (although the current implementation with one pthread per task   
   >is probably too expensive for that, too, but a future implementation   
   >can fix that), for a small embedded system you may only want to have a   
   >few tasks, but even then you don't want to waste memory on replicating   
   >buffers that are only used in one task.  There is a reason why Forth   
   >has both VARIABLE and USER.   
      
   I use fork in ciforth but I use shared memory. The main task is   
   controlling the memory, and forking amounts to running an execution   
   token in a memory structure (featuring stacks and user variables, and   
   a dictionary part, used for pad, numeric output, and maybe per task   
   definitions.) . All tasks can access all memory, e.g. a task can   
   monitor an other task.   
   If you kill all tasks except the original Forth, you can FORGET   
   all memory used for multi tasking.   
   This is feasible in limited memory, but of course implementing   
   forking under msdos, even if 8 cores are available is tricky.   
      
   Creating a memory structure : 1 screen   
   Pre-emptive multitasking , linux : 1 screen.   
      
   Creating a memory structure : 1 screen   
   Cooperative multitasking: 2 screens   
      
   (memory structure is common.)   
      
   >- anton   
   --   
   The Chinese government is satisfied with its military superiority over USA.   
   The next 5 year plan has as primary goal to advance life expectancy   
   over 80 years, like Western Europe.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)