Documentation
¶
Overview ¶
Package sync defines the logger.
sync is using a global logger with some default parameters. It is disabled by default and the level can be increased using an environment variable:
SYNCLOG=trace SYNCLOG=info
sync main feature is disabled by default and thus works seemingly like the original sync package from the standard. To enable the debugging feature, use the following environment variable, e.g:
SYNCON=true
Index ¶
Constants ¶
const EnvDebugSwitch = "SYNCON"
EnvDebugSwitch is the name of the environment variable to allow debugging.
const EnvLogLevel = "SYNCLOG"
EnvLogLevel is the name of the environment variable to change the logging level.
Variables ¶
var DebugIsOn = false
DebugIsOn allows to turn the debugging tool on
var Logger = zerolog.New(logout).Level(defaultLevel).
With().Timestamp().Logger().
With().Caller().Logger()
Logger is a globally available logger instance. By default, it only prints error level messages but it can be changed through a environment variable.
var Timeout = 10 * time.Second
Functions ¶
This section is empty.
Types ¶
type Cond ¶
Cond implements a condition variable, a rendezvous point for goroutines waiting for or announcing the occurrence of an event.
type Map ¶
Map is like a Go map[interface{}]interface{} but is safe for concurrent use by multiple goroutines without additional locking or coordination. Loads, stores, and deletes run in amortized constant time.
type Mutex ¶
type Mutex struct {
// contains filtered or unexported fields
}
A Mutex is a mutual exclusion lock. The zero value for a Mutex is an unlocked mutex.
A Mutex must not be copied after first use.
In the terminology of the Go memory model, the n'th call to Unlock “synchronizes before” the m'th call to Lock for any n < m. A successful call to TryLock is equivalent to a call to Lock. A failed call to TryLock does not establish any “synchronizes before” relation at all.
func (*Mutex) Lock ¶
func (m *Mutex) Lock()
Lock locks m. If the lock is already in use, the calling goroutine blocks until the mutex is available.
type RWMutex ¶
type RWMutex struct {
// contains filtered or unexported fields
}
A RWMutex is a reader/writer mutual exclusion lock. The lock can be held by an arbitrary number of readers or a single writer. The zero value for a RWMutex is an unlocked mutex.
A RWMutex must not be copied after first use.
If a goroutine holds a RWMutex for reading and another goroutine might call Lock, no goroutine should expect to be able to acquire a read lock until the initial read lock is released. In particular, this prohibits recursive read locking. This is to ensure that the lock eventually becomes available; a blocked Lock call excludes new readers from acquiring the lock.
In the terminology of the Go memory model, the n'th call to Unlock “synchronizes before” the m'th call to Lock for any n < m, just as for Mutex. For any call to RLock, there exists an n such that the n'th call to Unlock “synchronizes before” that call to RLock, and the corresponding call to RUnlock “synchronizes before” the n+1'th call to Lock.
func (*RWMutex) Lock ¶
func (m *RWMutex) Lock()
Lock locks rw for writing. If the lock is already locked for reading or writing, Lock blocks until the lock is available.
func (*RWMutex) RLock ¶
func (m *RWMutex) RLock()
RLock locks rw for reading.
It should not be used for recursive read locking; a blocked Lock call excludes new readers from acquiring the lock. See the documentation on the RWMutex type.
func (*RWMutex) RUnlock ¶
func (m *RWMutex) RUnlock()
RUnlock undoes a single RLock call; it does not affect other simultaneous readers. It is a run-time error if rw is not locked for reading on entry to RUnlock.
func (*RWMutex) TryLock ¶
TryLock tries to lock rw for writing and reports whether it succeeded.
Note that while correct uses of TryLock do exist, they are rare, and use of TryLock is often a sign of a deeper problem in a particular use of mutexes.
func (*RWMutex) TryRLock ¶
TryRLock tries to lock rw for reading and reports whether it succeeded.
Note that while correct uses of TryRLock do exist, they are rare, and use of TryRLock is often a sign of a deeper problem in a particular use of mutexes.
func (*RWMutex) Unlock ¶
func (m *RWMutex) Unlock()
Unlock unlocks rw for writing. It is a run-time error if rw is not locked for writing on entry to Unlock.
As with Mutexes, a locked RWMutex is not associated with a particular goroutine. One goroutine may RLock (Lock) a RWMutex and then arrange for another goroutine to RUnlock (Unlock) it.
type WaitGroup ¶
type WaitGroup struct {
// contains filtered or unexported fields
}
func (*WaitGroup) Add ¶
Add adds delta, which may be negative, to the WaitGroup counter. If the counter becomes zero, all goroutines blocked on Wait are released. If the counter goes negative, Add panics.
Note that calls with a positive delta that occur when the counter is zero must happen before a Wait. Calls with a negative delta, or calls with a positive delta that start when the counter is greater than zero, may happen at any time. Typically this means the calls to Add should execute before the statement creating the goroutine or other event to be waited for. If a WaitGroup is reused to wait for several independent sets of events, new Add calls must happen after all previous Wait calls have returned. See the WaitGroup example.
Source Files