- 20 Dec, 2014 1 commit
-
-
Christian Couder authored
Otherwise there is the following failure when running godep restore: fatal: reference is not a tree: 281b085dc602c4f0377438e20331f45a91bcdf9c godep: restore: exit status 128 License: MIT Signed-off-by:Christian Couder <chriscool@tuxfamily.org>
-
- 19 Dec, 2014 1 commit
-
-
Jeromy authored
-
- 18 Dec, 2014 38 commits
-
-
Juan Batiz-Benet authored
Bitswap rounds
-
Brian Tiger Chow authored
@whyrusleeping License: MIT Signed-off-by:Brian Tiger Chow <brian@perfmode.com>
-
Jeromy authored
-
Brian Tiger Chow authored
addresses... https://github.com/jbenet/go-ipfs/pull/438/files#r21878994 License: MIT Signed-off-by:
-
Brian Tiger Chow authored
License: MIT Signed-off-by: -
Brian Tiger Chow authored
@whyrusleeping may wanna have a look and make sure i didn't screw anything up here BenchmarkInstantaneousAddCat1MB-4 200 10763761 ns/op 97.42 MB/s BenchmarkInstantaneousAddCat2MB-4 panic: runtime error: invalid memory address or nil pointer dereference [signal 0xb code=0x1 addr=0x0 pc=0xbedd] goroutine 14297 [running]: github.com/jbenet/go-ipfs/exchange/bitswap/decision.(*taskQueue).Remove(0xc2087553a0, 0xc2085ef200, 0x22, 0x56f570, 0xc208367a40) /Users/btc/go/src/github.com/jbenet/go-ipfs/exchange/bitswap/decision/taskqueue.go:66 +0x82 github.com/jbenet/go-ipfs/exchange/bitswap/decision.(*Engine).MessageSent(0xc20871b5c0, 0x56f570, 0xc208367a40, 0x570040, 0xc208753d40, 0x0, 0x0) /Users/btc/go/src/github.com/jbenet/go-ipfs/exchange/bitswap/decision/engine.go:177 +0x29e github.com/jbenet/go-ipfs/exchange/bitswap.(*bitswap).send(0xc20871b7a0, 0x56f4d8, 0xc208379800, 0x56f570, 0xc208367a40, 0x570040, 0xc208753d40, 0x0, 0x0) /Users/btc/go/src/github.com/jbenet/go-ipfs/exchange/bitswap/bitswap.go:352 +0x11c github.com/jbenet/go-ipfs/exchange/bitswap.(*bitswap).taskWorker(0xc20871b7a0, 0x56f4d8, 0xc208379800) /Users/btc/go/src/github.com/jbenet/go-ipfs/exchange/bitswap/bitswap.go:238 +0x165 created by github.com/jbenet/go-ipfs/exchange/bitswap.New /Users/btc/go/src/github.com/jbenet/go-ipfs/exchange/bitswap/bitswap.go:66 +0x49e -
Brian Tiger Chow authored
License: MIT Signed-off-by: -
Brian Tiger Chow authored
License: MIT Signed-off-by: -
Brian Tiger Chow authored
in many places, entries are assigned from one slice to another and in different goroutines. In one place, entries were modified (in the queue). To avoid shared mutable state, probably best to handle entries by value. License: MIT Signed-off-by: -
Brian Tiger Chow authored
not changing this because i don't want to write a test for it now License: MIT Signed-off-by: -
Brian Tiger Chow authored
addresses https://github.com/jbenet/go-ipfs/pull/438#discussion_r21952271 License: MIT Signed-off-by:
-
Brian Tiger Chow authored
License: MIT Signed-off-by: -
Brian Tiger Chow authored
addresses https://github.com/jbenet/go-ipfs/pull/438#discussion_r21953742 License: MIT Signed-off-by:
-
Brian Tiger Chow authored
License: MIT Signed-off-by: -
Brian Tiger Chow authored
License: MIT Signed-off-by: -
Brian Tiger Chow authored
License: MIT Signed-off-by: -
Brian Tiger Chow authored
only sort SortedEntries() License: MIT Signed-off-by: -
Brian Tiger Chow authored
this opens up the possibility of having multiple queues. And for all outgoing messages to be managed by the decision engine License: MIT Signed-off-by: -
Brian Tiger Chow authored
License: MIT Signed-off-by: -
Brian Tiger Chow authored
License: MIT Signed-off-by: -
Brian Tiger Chow authored
bitswap keeps the threadsafe version. observing the ledger shows that it doesn't need it anymore (ledgermanager is protected and safe). License: MIT Signed-off-by: -
Brian Tiger Chow authored
If we put the lock next to the fields it protects, it can sometimes make it easier to reason about threadsafety. In this case, it reveals that the task queue (not threadsafe) isn't protected by the mutex, yet shared between the worker and callers. @whyrusleeping License: MIT Signed-off-by: -
Brian Tiger Chow authored
it's only used in two places, but i think we've been using maps on IPFS types so much now that the specificity is no longer necessary License: MIT Signed-off-by: -
Brian Tiger Chow authored
License: MIT Signed-off-by: -
Brian Tiger Chow authored
Before, priority carried two pieces of information. One: priority as defined by remote peer Two: whether task is trashed This assumes the protocol is defined for natural numbers instead of integers. That may not always be the case. Better to leave that assumption outside so this package isn't coupled to the whims of the protocol. The protocol may be changed to allow any integer value to be used. Hopefully by that time, new responsibilties weren't added to the Priority variable. License: MIT Signed-off-by: -
Brian Tiger Chow authored
it seems to make sense since, in each place, the Key and Priority represent the same information b/c you know the saying... "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures." License: MIT Signed-off-by: -
Brian Tiger Chow authored
License: MIT Signed-off-by: -
Brian Tiger Chow authored
License: MIT Signed-off-by: -
Brian Tiger Chow authored
License: MIT Signed-off-by: -
Brian Tiger Chow authored
License: MIT Signed-off-by: -
Brian Tiger Chow authored
License: MIT Signed-off-by: -
Brian Tiger Chow authored
License: MIT Signed-off-by: -
Brian Tiger Chow authored
we've been using maps with peers long enough now that this probably is no longer necessary License: MIT Signed-off-by: -
Brian Tiger Chow authored
the less bitswap has to know about, the easier it'll be for readers. (This now returns Messages.) License: MIT Signed-off-by: -
Brian Tiger Chow authored
for clarity and to avoid errors, define a function License: MIT Signed-off-by: -
Brian Tiger Chow authored
License: MIT Signed-off-by: -
Brian Tiger Chow authored
(merely by convention) License: MIT Signed-off-by: -
Brian Tiger Chow authored
function should be a no-op when passed an empty slice License: MIT Signed-off-by:
-
