dexon - DEXON full node (https://github.com/dexon-foundation/dexon)

	Commit message (Collapse)	Author	Age	Files	Lines
*	all: import "context" instead of "golang.org/x/net/context"	Felix Lange	2017-03-23	1	-1/+1
\| \| \| \| \| \| \| \| \| \|	There is no need to depend on the old context package now that the minimum Go version is 1.7. The move to "context" eliminates our weird vendoring setup. Some vendored code still uses golang.org/x/net/context and it is now vendored in the normal way. This change triggered new vet checks around context.WithTimeout which didn't fire with golang.org/x/net/context.
*	all: blidly swap out glog to our log15, logs need rework	Péter Szilágyi	2017-02-23	1	-8/+3
\|
*	rpc: add context argument to EthSubscribe	Felix Lange	2016-08-06	1	-4/+4
\| \| \| \| \|	It's inconsistent not to pass it and most callers will work with contexts anyway.
*	rpc: ensure client doesn't block for slow subscribers	Felix Lange	2016-08-06	1	-0/+51
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	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.
*	rpc: add new client, use it everywhere	Felix Lange	2016-07-23	1	-0/+489
	The new client implementation supports concurrent requests, subscriptions and replaces the various ad hoc RPC clients throughout go-ethereum.