viuavm-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Viuavm-commits] [SCM] Viua VM branch issue-6329ca01-implement-i-o-instr


From: git
Subject: [Viuavm-commits] [SCM] Viua VM branch issue-6329ca01-implement-i-o-instructions updated. v0.9.0-2523-g88cc367
Date: Tue, 27 Aug 2019 22:54:31 +0200 (CEST)

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Viua VM".

The branch, issue-6329ca01-implement-i-o-instructions has been updated
       via  88cc36746afb8b506b5f4f9b3cc73cd1641bd13a (commit)
       via  a084ad796f384e309786414a3be7a60547088bca (commit)
       via  e5f54b094e9a4ceb3165abf01c8df0f01c199902 (commit)
      from  44a8c23277da297d102eba7565025a6d67525f3c (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 88cc36746afb8b506b5f4f9b3cc73cd1641bd13a
Author: Marek Marecki <address@hidden>
Date:   Tue Aug 27 22:27:32 2019 +0200

    I/O requests are attached to the kernel, not a process
    
    This avoids the segmentation faults that could have happened if an I/O
    request outlived the process that spawned it. When it went out of scope
    it tried to automatically cancel or abort itself by going through the
    process interface and, since the process was already destroyed, crashed
    the whole VM.
    
    Now this will not happen since the kernel outlives any other object.
    
    Sending I/O requests may be useful and attaching them to the kernel
    instead of to a process makes this possible.

commit a084ad796f384e309786414a3be7a60547088bca
Merge: e5f54b0 44a8c23
Author: Marek Marecki <address@hidden>
Date:   Sun Aug 25 23:00:16 2019 +0200

    Merge branch 'issue-6329ca01-implement-i-o-instructions' of 
git.sr.ht:~maelkum/viuavm into issue-6329ca01-implement-i-o-instructions

commit e5f54b094e9a4ceb3165abf01c8df0f01c199902
Author: Marek Marecki <address@hidden>
Date:   Sun Aug 25 09:37:34 2019 +0200

    Basic write interaction works
    
    With this change in place the most essential I/O (reading from standard
    input and writing to standard output) works without foreign modules,
    using just VM opcodes.
    
    What is left to be done is creating more interactions then refactoring
    common code out (while making provisions for custom interactions that
    are not implemented with POSIX I/O system calls). The scheduler should
    be rewritten to just fetch (file descriptors, opcode, data) tuples and
    wait for several I/O requests in parallel - we are already using the
    select(3) call, but wait for just one file descriptor which is terribly
    inefficient.
    
    Also, prevent sending I/O request handles between processes for now
    since destroying them causes segmentation fault. A better scheme for
    aborting and cancelling requests should be devised - an I/O request
    being cancelled after it goes out of scope and was not waited for MUST
    NOT crash the VM.
    
    Another thing is to prevent several I/O schedulers from fetching I/O
    requests for the same file descriptor. We would not want to run several
    writes in parallel to avoid corrupting the data. Something like this is
    probably needed:
    
        auto q = std::queue<I/O request*>{};
        auto q_map = std::map<fd, std::queue<I/O request>>{};
        auto fd_grabbed_by = std::map<fd, I/O scheduler*>{};
    
    The 'q' field is used to notify the schedulers about work. A scheduler
    then checks the fd associated with the request and checks if it is free
    to run it - the condition is true if no scheduler has grabbed the fd, or
    if the scheduler that did grab the fd is the scheduler checking. If the
    scheduler may run the request it fetches the real request (not just the
    pointer); otherwise it checks the next request on the queue.
    
    Maybe reads and writes can be run in parallel? Should it be configurable
    when opening the port? The I/O subsystem will definitely grow more
    complex...

-----------------------------------------------------------------------

Summary of changes:
 include/viua/scheduler/process.h |  4 ++
 include/viua/types/io.h          | 27 ++++++++----
 io.asm                           | 33 ++++++++++-----
 src/process.cpp                  |  2 +-
 src/process/instr/io.cpp         | 17 +++-----
 src/types/io.cpp                 | 90 ++++++++++++++++++++++++++++++++++------
 6 files changed, 129 insertions(+), 44 deletions(-)


hooks/post-receive
-- 
Viua VM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]