GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
Has anyone tried to compile and run RethinkDB on an ARM hardware?
I have. We have some inlined assembly that needs to be ported over to arm and I assume some system calls that will need to change. This is something of low corporate priority but medium personal priority to me.
Keep up the good work RethinkDB team. Really enjoyed using rethinkdb.
Would love to be able to run RethinkDB on RaspberryPI. +++++
I've started trying to implement this, but I've hit a bit of a snag. In debug mode, the watchdog code uses rdtsc as a high-resolution timer. This is not portable, and in particular, there is no real equivalent on ARM. My plan for now is to fake it by attempting to measure nanoseconds instead of cycles, pretending that they are the same thing, using clock_gettime. Would anyone like to chime in on this?
@davidthomas426 We are probably going to get rid of the watchdog anyway. Independent of that, you could just disable it under ARM through some #ifndefs. The watchdog is just a debug tool for identifying performance issues, nothing of importance for RethinkDB to work.
@davidthomas426 -- I just want to chime in and say that what you're doing is awesome! Please keep us posted on your progress. Also, if you fill out the form here http://www.rethinkdb.com/community/shirts-for-stories/ we'd love to send you some goodies :)
Also, if that is less of a hassle than having to put #ifndefs everywhere: Using clock_gettime() as a replacement in the watchdog sounds perfectly fine to me.
I got it working without compiler optimization, but with optimization I'm having problems when a coroutine migrates to another thread and then accesses thread-local storage. For example, suppose a coroutine is on thread 0, and wants to move to thread 1. The optimizer causes the coroutine to cache the thread pointer for thread 0 in a register, then move to thread 1, then use the cached thread pointer, which is now incorrect.
A Google search revealed other people discussing this problem, which is not just for ARM:
David, that's awesome! Are you planning to submit a pull request? I can't promise we'll merge it in (because of added maintenance burden), but we are looking forward to getting Rethink to run on a Raspberry Pi :)
It only works when compiled without optimization, so I didn't want to submit a pull request yet. With optimization, the first thread-local access after a coroutine migrates to a different thread results in a segfault (because it's looking at the wrong thread's version of the thread-local). The problem is, I'm not sure how to fix this problem (well, short of something crazy...like storing a global array for each thread-local variable storing the addresses of the variable on each thread, and using the gettid syscall to find out what thread I'm on every time I want to access TLS).
I've posted a question on stackoverflow about it at http://stackoverflow.com/questions/19811474/how-do-i-force-g-on-linux-to-update-the-thread-pointer-for-tls-when-a-corout
@davidthomas426 -- I know there is still an optimization issue, we just wanted an ARM branch to play with in the meantime :) Also, I just commented on stack overflow with some ideas on how to get this fixed.
I sent you a separate e-mail a day or so ago (to the e-mail on your github profile). If you didn't get it, could you shoot me an e-mail to email@example.com ?
@davidthomas426 For your information: With newer versions of GCC (4.8), we are now hitting the same issue with compiler optimizations on i386 as well. See #1731 (comment)
I'm sure we will find a solution to this somehow.
Closed by #1625.