mirror of
https://github.com/valyala/fasthttp.git
synced 2026-06-13 15:46:49 +03:00
Moritz Poldrack
d0f2727a4d
* 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
56 lines
1.2 KiB
Go
56 lines
1.2 KiB
Go
package fasthttp
|
|
|
|
import (
|
|
"sync"
|
|
"time"
|
|
)
|
|
|
|
func initTimer(t *time.Timer, timeout time.Duration) *time.Timer {
|
|
if t == nil {
|
|
return time.NewTimer(timeout)
|
|
}
|
|
if t.Reset(timeout) {
|
|
// developer sanity-check
|
|
panic("BUG: active timer trapped into initTimer()")
|
|
}
|
|
return t
|
|
}
|
|
|
|
func stopTimer(t *time.Timer) {
|
|
if !t.Stop() {
|
|
// Collect possibly added time from the channel
|
|
// if timer has been stopped and nobody collected its value.
|
|
select {
|
|
case <-t.C:
|
|
default:
|
|
}
|
|
}
|
|
}
|
|
|
|
// AcquireTimer returns a time.Timer from the pool and updates it to
|
|
// send the current time on its channel after at least timeout.
|
|
//
|
|
// The returned Timer may be returned to the pool with ReleaseTimer
|
|
// when no longer needed. This allows reducing GC load.
|
|
func AcquireTimer(timeout time.Duration) *time.Timer {
|
|
v := timerPool.Get()
|
|
if v == nil {
|
|
return time.NewTimer(timeout)
|
|
}
|
|
t := v.(*time.Timer)
|
|
initTimer(t, timeout)
|
|
return t
|
|
}
|
|
|
|
// ReleaseTimer returns the time.Timer acquired via AcquireTimer to the pool
|
|
// and prevents the Timer from firing.
|
|
//
|
|
// Do not access the released time.Timer or read from its channel otherwise
|
|
// data races may occur.
|
|
func ReleaseTimer(t *time.Timer) {
|
|
stopTimer(t)
|
|
timerPool.Put(t)
|
|
}
|
|
|
|
var timerPool sync.Pool
|