Contract Registry - trait and centralized implementation #182
Conversation
willscott
added
p:1
What do you mean by itself? A contract has a public key? Who has the private part, the key manager? |
registry/dummy/src/contract.rs
Outdated
| let mut inner = inner.lock().unwrap(); | ||
| inner.contracts.insert(contract.id, contract.clone()); | ||
|
|
||
| inner.notify(&contract); |
There was a problem hiding this comment.
This may lead to a deadlock in case the gRPC executor is used (which we are currently using). The issue is that with the gRPC executor, as an optimization, notifying a task may poll the task immediately if it is running on the same thread. In this concrete case, when you call unbounded_send above, it will cause the receiver task (the one that is running the get_contracts futrue) to get notified and the gRPC executor will immediately poll the task (e.g., before unbounded_send returns). If that task then polls any registry future that takes the same lock, this will cause a deadlock because the lock is still held and mutexes in Rust are not recursive.
For this reason I had to complicate the dummy consensus backend and introduce more granular locking in #172 (see the dummy consensus backend changes). Thinking about it now, the most correct thing would be to avoid taking any lock while calling unbounded_send, but this way you cannot remove subscribers. Perhaps a RwLock would be the correct primitve to use here.
There was a problem hiding this comment.
I've implemented a general structure for handling stream subscribers in #183.
Just refactor your code to release the inner lock before calling its notify (e.g. make locks more granular so that there is a mutex covering inner.contracts but not inner.subscribers and that inner is only in an Arc without a Mutex).
|
As in: what signatures do we associate with contact registration.
Is an `Entity` going to sign that registration?
The main reason to have contracts be associated with entities is that it
would let us tie into the e.g. stake system if we need to do accounting /
limit dos potential.
…On Fri, May 4, 2018 at 2:28 AM, Jernej Kos ***@***.***> wrote:
does a contract own itself? Should it be signed / owned by an entity?
What do you mean by itself? A contract has a public key? Who has the
private part, the key manager?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#182 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAaIp-6PU0S-hxvXOaJWjJSg6ENXVqCKks5tvB80gaJpZM4TxtXe>
.
|
|
What is an entity in this case? The contract creator?
|
|
Right: the question is - there's a keypair somewhere that's gonna be
associated with the address account and "value" that's considered held by
the contract. Do we consider that directly part of a contract, which I
believe is how ethereum is structured, or do we introduce a level of
indirection, so that e.g. multiple contracts can be considered to be
operated by the same "entity".
…On Fri, May 4, 2018 at 9:10 AM, Jernej Kos ***@***.***> wrote:
What is an entity in this case? The contract creator?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#182 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAaIp0Zqi6zgN59nfBJFq3OKGXz1H9kVks5tvH10gaJpZM4TxtXe>
.
|
registry/base/src/lib.rs
Outdated
|
|
||
| pub use backend::*; | ||
| pub use contract_backend::*; |
There was a problem hiding this comment.
If this is now contract_backend, could we name the other one entity_backend? And the same for services. Otherwise it looks a bit confusing.
|
for now, we'll have the contract id pubkey not have explicit relationship with an 'entity' - since there are lifetime issues (entities can be deregistered, unlike contracts). |
cargo fmt Implement StreamSubscribers per #183 rename registry 'backend' to 'entity' throughout fmt
willscott
force-pushed
the
willscott/feature/contract-registry
branch
from
8569489
to
12acb2c
Compare
Parallel to the entity / node registry