dont need blockservice workers anymore #1622
Conversation
|
Agree there's duplicated logic here, but I'm not sure this is right. Would like to see some benchmarks for this, when adding huge things in a networked environment.
an add operation should be completely decoupled from providing to the network. maybe should be using notifications/events for this: |
|
@jbenet bitswap never blocks on add: https://github.com/ipfs/go-ipfs/blob/master/exchange/bitswap/workers.go#L124-L134 |
| @@ -67,7 +46,7 @@ func (s *BlockService) AddBlock(b *blocks.Block) (key.Key, error) { | |||
| if err != nil { | |||
| return k, err | |||
| } | |||
| if err := s.worker.HasBlock(b); err != nil { | |||
| if err := s.Exchange.HasBlock(context.TODO(), b); err != nil { | |||
There was a problem hiding this comment.
thinking that this HasBlock is a passive activity, not an active one like the "AddBlock" call. i.e. user is adding, not wanting to write out. or send blocks to others. may be worth doing .HasBlock in a goroutine/process/worker.
context should be derived from some context passed to the blockservice initially, not the current request, i think.
|
@jbenet can has merge? |
|
needs rebase. assign me when done |
whyrusleeping
force-pushed
the
feat/rm-worker
branch
2 times, most recently
from
e49cb94 to
3d2f516
Compare
ghost
mentioned this pull request
|
@whyrusleeping did it get out of date again? |
|
sorry |
|
I can rebase again, this ones pretty easy compared to some of the others, lol |
License: MIT Signed-off-by: Jeromy <jeromyj@gmail.com>
License: MIT Signed-off-by: Jeromy <jeromyj@gmail.com>
whyrusleeping
force-pushed
the
feat/rm-worker
branch
from
3d2f516 to
63f72a5
Compare
|
@jbenet rebased. |
dont need blockservice workers anymore
The worker in blockservice was useless. We buffer outgoing provides in bitswap anyways, removing the workers here will make things a bit simpler.
TODO:
License: MIT
Signed-off-by: Jeromy jeromyj@gmail.com