This commit introduces a simple thread-safe ring buffer implementation
based on top of BDataIO. The main use case for this class will be to
implement shared buffers between threads for the upcoming refactoring
of Services Kit.
Change-Id: I526bc044b28c91496ad996fabebe538e75647f2c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2966
Reviewed-by: Jacob Secunda <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Previously, BUrlRequest returns data received via a callback that can't
return any value. This approach have several issues:
- It's not possible to signify failures to the request.
- Users have to implement custom listeners just to handle the common
case of outputting to a buffer/file/etc.
- The received data has to be serialized into BMessage when
BUrlProtocolDispatchingListener is employed. This can cause a
noticible slowdown in real-world scenarios as evident by #10748.
With this change, BUrlRequest will output directly into a BDataIO, which
exposes a richer API for request handlers to work with (for example a
BitTorrent client can request a BPositionIO for non-linear data
delivery), as well as simplifying common cases for users.
The adaptation only requires one additional API:
BHttpRequest::SetStopOnError(). This API simply instructs the HTTP
request handler to cancel the request if an HTTP error is occurred.
Change-Id: I4160884d77bff0e7678e0a623e2587987704443a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3084
Reviewed-by: Adrien Destugues <[email protected]>
The switch to make BUrlResult serializable was debuted in
f9e1854f19 with the rationale is that
BHttpRequest auto-redirection might cause the headers to become
obsolete by the time a client process the BMessage received from
BUrlProtocolDispatchingListener.
With the change to BHttpRequest to not notify listeners when
auto-redirection is enabled, this is no longer the case and the
serialization code can go away now. This simplifies BUrlResult and its
subclasses, and gain us some performance for clients using
BUrlProtocolDispatchingListener as the result object no longer has to be
serialized.
This also change the ABI of BUrlProtocolListener::HeadersReceived to no
longer passing a BUrlResult.
Additionally, BUrlResult and BHttpResult now express the size of the content
as an off_t, thus allowing results larger than 4 GB.
Change-Id: I9dd29a8b26fdd9aa8e5bbad8d1728084f136312d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3082
Reviewed-by: Adrien Destugues <[email protected]>
When the user enable auto-redirection, what they meant is that they do
not want to handle redirections, thus we should take total control of this
step and hide it from the user. In fact, a majority of in-tree users
write code to disable their listener when a redirection happen.
This should also allow us to simplify BUrlResult, which has been turned
into a BArchivable for the sole reason of "preserving" headers when
auto redirect is enabled when used with BUrlDispatchingListener, which
has been shown to have little (if any) practical usage.
Change-Id: I9b10b81de0a13edbaec25f6b48ed7a4335ea691a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3081
Reviewed-by: Adrien Destugues <[email protected]>
This API change forces all creation of BUrlRequest to be done via
BUrlProtocolRoster::MakeRequest(). This allows the structure of protocol
addons to be altered without breaking ABI for client applications.
Change-Id: I1785c9136c50d19eaa9e57cb9d259ed8d88a5b56
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3080
Reviewed-by: waddlesplash <[email protected]>
The socket is a blocking one, which means Read() will block unless data
is available, thus WaitForReadable() is useless in this context.
Testing also shows a 2x performance increase from removing this call due
to poll() performance being botched when KDEBUG_LEVEL >= 2.
Change-Id: I3170f865e961112b420c1548726bb6fd38e94cb2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3078
Reviewed-by: waddlesplash <[email protected]>
This make sure that the temporary buffer will always be deleted should
any premature return happens.
Change-Id: I448ec7c3f3eeca1ef2b6473b49323f34bcb7bf86
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3077
Reviewed-by: waddlesplash <[email protected]>
Instead we can trigger a Read() immediately, as our socket is blocking
and won't return until some data has been made available. This avoids a
potentially costly syscall in the loop body.
Change-Id: I899f55ede41af7cb7e9311aa04006b33c40d3ee4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3076
Reviewed-by: waddlesplash <[email protected]>
This commit brings the following changes:
- DownloadProgress() should now be reported for every DataReceived()
calls, similar to other BUrlRequest classes.
- Properly verify whether a listener has been set before invoking them.
Change-Id: I4ded82e318ba580b8869c3d1751da4e36882c39f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3075
Reviewed-by: waddlesplash <[email protected]>
This simplify the clean up code path and make sure that the temporary
buffer will always be freed on exit.
Change-Id: I70c1a25bfa66c4f4a96dd3d0af3765a67e305fb2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3074
Reviewed-by: waddlesplash <[email protected]>
Trigger DownloadProgress after DataReceived, similar to how other BUrlRequest
classes behave.
Change-Id: I4858c3736b1b1ebec55af9903dbfd4b976a77df3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3073
Reviewed-by: waddlesplash <[email protected]>
Make BFileRequest reports download progress after every DataReceived()
calls.
DownloadProgress() format has also been changed to use 0 as
`bytesTotal` when the total size is unknown. This is similar to
BHttpRequest functions currently.
Change-Id: I2920ea00c4f841bb666425be6f8da418e913c727
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3072
Reviewed-by: waddlesplash <[email protected]>
This commit implements a check for the flag raised by Stop() to cancel
a given request as soon as possible. Cancelled requests will return
B_INTERRUPTED regardless of whether the request has completed,
on par with how BHttpRequest is behaving at the moment.
Change-Id: Ia8a95b910cff158c710c5b2ed58b4675e705642e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3071
Reviewed-by: waddlesplash <[email protected]>
`atoi()` maximum value is `LONG_MAX` which is smaller than `SIZE_MAX`.
This cause any Content-Length > LONG_MAX to be represented in an
erroneous value. This will also happen to any invalid Content-Length
header.
This change uses strtoul() for the extended range (should be the same as
size_t range), and combined with proper error checking to determine
whether the received Content-Length is a valid and/or representable
value. Returns 0 if the data is invalid or can not be represented.
Some shortcomings about the current implementation are also
noted accordingly. They will be solved in later patches.
Change-Id: If28c4c3b8430ed83dd0f600030ec8949cf7e0051
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2927
Reviewed-by: waddlesplash <[email protected]>
Per POSIX.1-2008, getpeername() shall fails if the socket is not
connected.
With this change, it's no longer possible to retrieve the peer from
connectionless protocols such as UDP, even if a peer is assigned to them
via connect(). The same behavior can be replicated among
POSIX-compatible operating systems such as Linux.
Fixes#15081
Change-Id: Ia5631971200959a3d3815332ff1969c4b4dd289b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2421
Reviewed-by: Jérôme Duval <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
_CollectCopyInfo uses fBytesToCopy and fItemsToCopy for the sole purpose
of returning the scan results. This variable in turn was used to add to
the amount of files to copy in the progress bar, causing it to grow
exponentially with every CollectTargets calls.
With the current use case, the variable would have to be reset to 0
everytime CollectTargets is invoked, making it rather useless as a class
state.
This commit turns those variables into _CollectCopyInfo return values,
and also fix the exponential growth of the progress bar target.
Fixes#15826
Change-Id: Ib734febfdd8aaaa12fdfac61be124adb61b28f6c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2445
Reviewed-by: waddlesplash <[email protected]>
Most of Installer was designed for old-style optional packages (files in
a folder that's copied to the target volume). This commit modifies
Installer so that it can process and install .hpkg packages.
Change-Id: Ib7d69a04ccb7879b956b5c3f0df1241c56e4987d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2400
Reviewed-by: waddlesplash <[email protected]>
Previously this class exposes two methods:
- CopyFile(): only copy the file data, nothing else.
- CopyFolder(): copy files & directories between two folders, while
preserving the attributes as well as symlinks.
With this commit, everything is unified into one method: Copy(). This
method can handle files, directories, symlinks and optionally also copy
attributes. Since most of the logic was just moved around, we can be
rather certain that this won't disrupt CopyEngine behaviors by much.
In the future we should look into using BCopyEngine to replace the
copying part of CopyEngine, as they seems to be compatible.
This change allows the Installer to make use of CopyEngine as a
general-purpose copier, in preparation for optional .hpkg installation
support.
Change-Id: Iad5ba2ebc9f34b7822e550b415308fd2b43eed47
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2399
Reviewed-by: waddlesplash <[email protected]>
CollectCopyInfo was designed to process directories only. This commit
makes it more versatile and works with everything instead.
Change-Id: Ifa74db3815411f7348e3bcc230842710058b1111
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2398
Reviewed-by: waddlesplash <[email protected]>
This header was not included when Haiku is built with KDEBUG_LEVEL=0,
causing build failures.
Change-Id: I690064f7c1a9818056a394e2655811775c4cc554
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2360
Reviewed-by: waddlesplash <[email protected]>
**Lots** of syscalls here don't check if strlcpy truncated the user
supplied argument. This commit adds them where appropriate.
Closes#2642
Change-Id: Iff89055aeb3a1870c8baf327b60873ce85815cd7
Reviewed-on: https://review.haiku-os.org/c/890
Reviewed-by: waddlesplash <[email protected]>
If available, getifaddrs() will now return additional entries for
different addresses of an interface. This is similiar to how NetBSD does
it.
This allows software such as libuv to construct detailed information
about network interfaces within the system.
Adrien have some concerns about getaddrinfo() wouldn't correctly exclude
IPv6 addresses after this change so a test was added to cover that.
Change-Id: I8c5d3a02b9294d746ca928a285f40344dfd6e3cb
Reviewed-on: https://review.haiku-os.org/c/874
Reviewed-by: Adrien Destugues <[email protected]>
Leorize