`Stream` will be qualified as `AK::Stream` until we remove the
`Core::Stream` namespace. `IODevice` now reuses the `SeekMode` that is
defined by `SeekableStream`, since defining its own would require us to
qualify it with `AK::SeekMode` everywhere.
Having an alias function that only wraps another one is silly, and
keeping the more obvious name should flush out more uses of deprecated
strings.
No behavior change.
`Process::get_name()` and `Process::set_name()` are basically the same
as `get_process_name()` and `set_process_name()`, except making use of
convenient Serenity standard types and returning ErrorOr, instead of
char* and errno shenanigans.
`Process::set_name()` has an optional `SetThreadName` parameter, for
when you also want to set the thread's name to the same thing. That's
true for the two places that use `set_process_name()`.
Besides from a general check if a file's directory has write
permissions, this also checks if the directory has set a sticky bit,
meaning that only file owners and the directory owner can remove or move
files in such directory. It's being used in /tmp for example.
At the moment, there is no immediate advantage compared to just calling
the underlying functions directly, but having a common interface feels
more ergonomic (users don't have to care about how a type serializes)
and maybe we'll find a way to hide the actual implementation from direct
access some time in the future.
The macOS FileWatcher depends on macOS dispatch queues, which run on a
different thread than the Core::EventLoop. This implementation handles
filesystem events on its dispatch queue, then forwards the event back to
the main Core::EventLoop for notifying the FileWatcher owner.
This will be handy for platforms which need to be able to store extra
OS-specific members. For example, macOS needs to store a dispatch queue,
and event stream, etc.
A negative return value doesn't make sense for any of those functions.
The return types were inherited from POSIX, where they also need to have
an indicator for an error (negative values).
InodeWatcherFlags is an enumeration from the Kernel. To avoid using it
outside of Serenity, add a FileWatcherFlags for FileWatcher, much like
we already have FileWatcherEvent::Type.
This is currently being implicitly including by InodeWatcherEvent.h by
way of FileWatcher.h. The former will soon be removed from the latter,
which would otherwise cause a compile error in these files.
This implements FileWatcher using inotify filesystem events. Serenity's
InodeWatcher is remarkably similar to inotify, so this is almost an
identical implementation.
The existing TestLibCoreFileWatcher test is added to Lagom (currently
just for Linux).
This does not implement BlockingFileWatcher as that is currently not
used anywhere but on Serenity.
This saves us an actual seek and rereading already stored buffer data in
cases where the seek is entirely covered by the currently buffered data.
This is especially important since we implement `discard` using `seek`
for seekable streams.
While at it, rename the `read_trivial_value` and `write_trivial_value`
functions to `read_value` and `write_value` respectively, since we'll
add compatibility for non-trivial types down the line.
We don't need to call `can_read_line()` as the buffer will be populated
by `find_and_populate_until_any_of()`. The change is also beneficial as
the buffer will be populated until a candidate is found and not
necessarily a new line.
The search used to go through the buffer from the start, even if we just
appended a small number of bytes at the end. It now remembers the last
stop and resume the search from it.
This parameter allows to start searching after an offset. For example,
to resume a search.
It is unfortunately a breaking change in API so this patch also modifies
one user and one test.
Ladybird currently doesn't render any webpages on FreeBSD and throws
hundreds of errors,beginning with this:
IPC::ConnectionBase (0x0000000805bf2b00) had an error (File descriptor
passing not supported on this platform), disconnecting.
WebContent process crashed!
There is no particular reason why we shouldn't allow zero-sized reads or
writes here, and this actually might cause issues with our common
stream-to-stream copy pattern if we end up at an unfortunate offset
where the next read would be zero-sized and trigger EOF only after that.
This was unintuitive, and only useful in a few cases. In the majority,
users had to immediately call `stop()`, and several who did want the
timer started would call `start()` on it immediately anyway. Case in
point: There are only two places I had to add a manual `start()`.
