You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
KVStore may do some business logic (see wotstore which update some trust), and are very likely to be composed by multiple internal KVStore in complex application.
This is very flexible design, yet we have no knowledge of underlying storage performance, and in some case some internal store may not be related at all (dht use only one keyval type which may map totally distinct KeyVal).
So we may have some dht managing many different concept (keyval) with multiple storage and yet a single thread to store those (lesser concept may be bottleneck for more prioritary concept).
Therefore we NEED to be able to run multiple thread for kvstore, two approach (the second one seems to be the right one) :
kvstore is multithreaded, on add_val or get_val, key or keyval are routed to the right underlying kvstore thread by using a new message in a new channel (costly since kvstore interface does not use a message)
A KVselector rule which unwrap message and send it to the right kvstore (it should have its own interface without a channel so it has no impact when using one store only). Use an array of KVStore and two function, one giving indice of store for a keyval and another giving indice of store for a key. boot_server function should evolve to launch multiple storage (array of storage init fn), running context will have an array of kvstore, and sending of kvstore message will allways use the kvselector on front.
The text was updated successfully, but these errors were encountered:
KVStore may do some business logic (see wotstore which update some trust), and are very likely to be composed by multiple internal KVStore in complex application.
This is very flexible design, yet we have no knowledge of underlying storage performance, and in some case some internal store may not be related at all (dht use only one keyval type which may map totally distinct KeyVal).
So we may have some dht managing many different concept (keyval) with multiple storage and yet a single thread to store those (lesser concept may be bottleneck for more prioritary concept).
Therefore we NEED to be able to run multiple thread for kvstore, two approach (the second one seems to be the right one) :
The text was updated successfully, but these errors were encountered: