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
I'm using RocksDB in a program that relies on a custom threading library. It's works fine because RocksDB spawns and manage its own POSIX threads, and because I make sure I access RocksDB from only one of my custom threads. Now, I could get more performance if I could make RocksDB use my threads and mutex instead of its own. I have seen various abstract classes like ThreadPool in the RocksDB headers. Is it possible to inject a custom threading layer into RocksDB via some of its abstract classes? Essentially I would need to make RocksDB not just use my threads, but also custom mutex/lock/condition variable classes that my threading library uses, in place of the POSIX ones.
How would you go about doing that?
The text was updated successfully, but these errors were encountered:
My guess is that this is not a trivial operation. If I were you, I would
attack it as follows:
1- Find the places that use a thread or mutex (and related classes) and
replace those with variants in the "port" namespace (redirection for most)
2- You may also need to do something for thread-local variables.
3- Write your own version of the port classes and interject them
4- You may need to implement your own Env class for the Thread-related
functions
Note that #1 and #2 would be things to contribute back as PRs to RocksDB
whereas #3/#4 are more likely proprietary code.
Note that the port namespace would allow you to pick your own packages at
compile-time. To do something like this at run-time would be more
complicated.
Good luck!!
/ Mark
On Thu, Sep 15, 2022 at 10:41 AM Matthieu Dorier ***@***.***> wrote:
I'm using RocksDB in a program that relies on a custom threading library.
It's works fine because RocksDB spawns and manage its own POSIX threads, on
one hand, and because I make sure I access RocksDB from only one of my
custom threads. Now, I could get more performance if I could make RocksDB
use my threads and mutex instead of its own. I have seen various abstract
classes like ThreadPool in the RocksDB header. Is it possible to inject a
custom threading later into RocksDB via some of its abstract classes?
Essentially I would need to make RocksDB not just use my threads, but also
custom mutex/locks/condition variables classes that my threading library
uses, in place of the POSIX ones.
How would you go about doing that?
—
Reply to this email directly, view it on GitHub
<#10682>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABCTBCMW6KPO757PERDK4LV6MYTDANCNFSM6AAAAAAQNO6AFU>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
I'm using RocksDB in a program that relies on a custom threading library. It's works fine because RocksDB spawns and manage its own POSIX threads, and because I make sure I access RocksDB from only one of my custom threads. Now, I could get more performance if I could make RocksDB use my threads and mutex instead of its own. I have seen various abstract classes like
ThreadPool
in the RocksDB headers. Is it possible to inject a custom threading layer into RocksDB via some of its abstract classes? Essentially I would need to make RocksDB not just use my threads, but also custom mutex/lock/condition variable classes that my threading library uses, in place of the POSIX ones.How would you go about doing that?
The text was updated successfully, but these errors were encountered: