Remove the accidental io_close
Merge branch 'master' into devel
Check io_cancel and io_close instructions
The I/O instructions are now fully supported by the checker.
Add checks for io_write and io_wait instructions
The "Hello, World!" example can be compiled without --no-sa flag or
"no_sa" tag.
Update Changelog
Include information about I/O instructions.
Fix test
Yep, the stringification changed. Not a big deal.
Concatenate to always print a single string
This will make the write to stdout atomic and prevent the VM from
preempting a process between printing the first and second part of the
message.
Silence logs
They were useful during the initial development phase, but now are just
noise. Leave them in the source tree, though, in case you will be
debugging (and that's not an "if" - it's a "when") the code later.
Expose file descriptors and I/O kind of interactions
This will be needed to move the select(3)-ing code out of every
interaction's code and into the scheduler (meaning less duplicated
code).
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...
Add design doc for "new I/O"
Make the std::posix::network module work with IO_fd
If we have a type for file descriptors we should use it instead of
sticking with raw integers.
Add an example assembly program for I/O
A simple demonstration of how to use the I/O instructions. It reads data
from standard input.
Stringify IO_fd in a useful way
Expose the underlying file descriptor of IO_fd
Update the "Hello World!" example in README
It was using the print instruction but we have something better now.
Move IO_interaction type to another namespace
IO_interaction is not related to viua::types::Value so there was no good
reason why it should be put inside viua::types namespace. Therefore, it
was moved to viua::scheduler::io which is a more suitable place for it.
Interactions without fd should just fail
If we don't have any means of detecting and performing the actual I/O
operation then what's the point?