* Remove a redundant field and clarify the comments.
* Revert "Using atomic instead of mutex and delete scratch slice (#1833)"
This reverts commit 19c50cdc44.
* using atomic instead of mutex and delete scratch slice
* optimize struct
* fix default bool
* escape data race
* avoid the momentary change of wp.workersCount.
* removed unused tail (for now)
* little fixes
* fixed allocations
This option immediately exits the loop when the maximum number of vorkers is reached, rather than creating a new vorker if the limit is reached. This reduces the frequency of unnecessary operations and potential locks in sync.Pool
* Update for linter workerpool.go
Co-authored-by: Erik Dubbelboer <erik@dubbelboer.com>
* Update for lint#2 workerpool.go
Co-authored-by: Erik Dubbelboer <erik@dubbelboer.com>
* Update for lint#3 workerpool.go
Co-authored-by: Erik Dubbelboer <erik@dubbelboer.com>
* Update for lint#4 workerpool.go
* eliminating potential data races
---------
Co-authored-by: Erik Dubbelboer <erik@dubbelboer.com>
1. Reduce RequestHeader from 368 bytes to 360 bytes
2. Reduce Request from 816 bytes to 800 bytes
3. Reduce Response from 432 bytes to 416 bytes
4. Reduce Client from 312 bytes to 288 bytes
5. Reduce HostClient from 416 bytes to 392 bytes
6. Reduce PipelineClient from 176 bytes to 168 bytes
7. Reduce pipelineConnClient from 216 bytes to 208 bytes
8. Reduce Cookie from 232 bytes to 224 bytes
9. Reduce FS from 184 bytes to 160 bytes
10. Reduce fsHandler from 168 bytes to 160 bytes
11. Reduce ResponseHeader from 328 bytes to 320 bytes
12. Reduce headerScanner from 128 bytes to 120 bytes
13. Reduce TCPDialer from 104 bytes to 96 bytes
14. Reduce workerPool from 152 btyes to 144 btyes
* client: simplify (*HostClient).do()
Remove an allocation in favour of deferring a call to release the
response.
* client: remove panic in dialAddr
Return an error instead of panicking if the user supplied a nonsensical
DialFunc.
* compression: remove panic on invalid compression level
If a compression level exceeding gzip's boundaries is provided, fasthttp
will panic. Instead it would be better to handle this error for them by
limiting it to the minimum or maximum value, depending on the direction
the user has exceeded the limits.
Clamp the value of gzip to always be between gzip.BestSpeed and
gzip.BestCompression.
* peripconn: remove panic on negative connection count
When a negative count is reached when unregistering a connection, a
panic is caused even though data-integrity is not at risk.
Replace the panic() with a simple clamp on the value to ensure the
value does not exceed it's expected lower bounds.
References: #1504
* compress: remove error on failed nonblocking writes
Since there is no way of handling or even logging non-critical errors in
stateless non-blocking writecalls, just drop them and hope the user
notices and tries again.
* workerPool: remove panic on redundant Start and Stop calls
Instead of panicking for invalid behaviour, it's preferable to just turn
the function into a noop.
* http: remove panic on invalid form boundary
* http: remove panic on negative reads
Since bufio already panics on negative reads, it is not necessary to do
so as well. If the length is zero and for some reason no error is
returned, readBodyIdentity and appendBodyFixedSize now errors in these
cases.
Link: https://github.com/golang/go/blob/851f6fd61425c810959c7ab51e6dc86f8a63c970/src/bufio/bufio.go#L246
* fs: remove panic on negative reader count
When a negative count is reached when unregistering a reader, a panic is
thrown even though data-integrity is not at risk.
Replace the panic() with a simple clamp on the value to ensure the
value does not exceed it's expected lower bounds.
* server: remove panic in favour of a segfault
Panicking with "BUG: " obscures the error. As the segfault causes a
panic anyway, just let the chaos unfold.
* server: remove panic in favour of returning an error
Writing on a timed-out response is not endangering data integrity and
just fails.
* chore: add comments to all panics
* chore: fix minor typo
* Use binary-search algorithm to speed up cleaning up workers
* Speed it up when iterating the slice of workerChan
* Use sync.Pool as a more canonical way
* Add benchmark test between binary-search and linear search
* Optimize range to the slice of workerChan, avoiding elements copy
* Perfect the benchmark of work pool
* Make binary-search code inline and remove benchmark test code
This implementation allows user to handle crypto/tls.Config.NextProtos to use their own handlers for the negotiated TLS protos like HTTP/2.
Workerpool where changed to adapt WorkerFunc to another conns server with ServeConn type and contains the Server structure which creates to check configured protos.
fasthttp returns a 431 error when the request headers are too large.
Most other HTTP servers do not log an error when the request header
exceeds the limit. When serving HTTP requests directly to browsers,
it is normal to occasionally hit the limit due to broken browsers
or broken sites linking to your resource. These issues are generally
outside of your control in the same way the already ignored errors are.
Erik Dubbelboer
newacorn
NikoMalik
Juan Calderon-Perez
Kashiwa
Oleksandr Redko
Moritz Poldrack
Andy Pan
Kevin Burns
Xu Qiaolun
Kirill Danshin
Aliaksandr Valialkin