summaryrefslogtreecommitdiff
path: root/src/kernel/handle.c
AgeCommit message (Collapse)Author
2023-01-11kernel: return EPIPE when fs_waiting on a dead filesystemdzwdz
2022-08-19syscall/fs_wait: return a handle for each requestdzwdz
2022-08-19kernel: kzallocdzwdz
2022-08-04do some simple TODOs, organize the rest; general code maintainancedzwdz
2022-07-09syscalls/pipe: turn into a POSIX-style api with separate rw endsdzwdz
Without separate read/write ends you can't tell when there are no more writers left if you have multiple readers. Consider this piece of code: int fd = pipe(); fork(); // execution continues in 2 processes while (read(fd, &some_buf, sizeof somebuf) >= 0) { ... } Once both processes call `read()`, it's obvious that no writes are possible - all the processes that hold a reference to the pipe are currently stuck on a `read()` call, so the kernel could just make it return an error in both. But, what then? It's still possible to write to the pipe, and you can't know if the other process will do that. Thus, if you don't want to miss any output, you have to keep reading the pipe. Forever. Both processes end up stuck. Having separate read/write ends prevents that.
2022-07-05kernel: initial partial pipe supportdzwdz
2022-05-06kernel: remove the union in `struct handle`dzwdz
2022-05-05kernel/vfs: rename the vfsreq funcs, merge vfsreq_finish & vfsreq_canceldzwdz
2022-05-04kernel: refcount vfs_backenddzwdz
what a mess
2022-05-02kernel/vfs: pass `close()` calls to fs handlersdzwdz
2022-05-01kernel/proc: make handles separate refcounted objectsdzwdz
2021-09-04nuke the old handle codedzwdz
2021-09-04rename file descriptors to handlesdzwdz