mirror of
https://gitlab.com/pulsechaincom/erigon-pulse.git
synced 2024-12-22 11:41:19 +00:00
f5f042ffdc
I initially made the client block if the 100-element buffer was
exceeded. It turns out that this is inconvenient for simple uses of the
client which subscribe and perform calls on the same goroutine, e.g.
client, _ := rpc.Dial(...)
ch := make(chan int) // note: no buffer
sub, _ := client.EthSubscribe(ch, "something")
for event := range ch {
client.Call(...)
}
This innocent looking code will lock up if the server suddenly decides
to send 2000 notifications. In this case, the client's main loop won't
accept the call because it is trying to deliver a notification to ch.
The issue is kind of hard to explain in the docs and few people will
actually read them. Buffering is the simple option and works with close
to no overhead for subscribers that always listen.
|
||
|---|---|---|
| .. | ||
| client_context_go1.4.go | ||
| client_context_go1.5.go | ||
| client_context_go1.6.go | ||
| client_context_go1.7.go | ||
| client_example_test.go | ||
| client_test.go | ||
| client.go | ||
| doc.go | ||
| errors.go | ||
| http.go | ||
| inproc.go | ||
| ipc_unix.go | ||
| ipc_windows.go | ||
| ipc.go | ||
| json_test.go | ||
| json.go | ||
| notification_test.go | ||
| notification.go | ||
| server_test.go | ||
| server.go | ||
| types_test.go | ||
| types.go | ||
| utils.go | ||
| websocket.go | ||