| Age | Commit message (Collapse) | Author |
|---|
|
* I'm being more strict about the linked list state to hopefully ensure
I'm not leaking any references.
* vfsreq_create was renamed to vfsreq_dispatchcopy as that name feels more
clear. It copies its argument, and dispatches it.
* Requests for user backends are now handled more like requests for kernel
backends - there's an accept() function that accepts a request.
|
|
|
|
I probably should've tested DUP_WRONLY too, now that I think about it. TODO?
|
|
|
|
|
|
I've wanted to do this for a while, and since I've just had a relatively
large refactor commit (pcpy), this is as good of a time as any.
Typedefing structs was mostly inspired by Plan 9's coding style. It makes
some lines of code much shorter at basically no expense.
Everything related to userland kept old-style struct definitions, so as not
to force that style onto other people.
I also considered changing SCREAMING_ENUM_FIELDS to NicerLookingCamelcase,
but I didn't, just in case that'd be confusing.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
what a mess
|
|
|
|
|
|
|
|
|
