Use a mutex to synchronize access to shared hashtable (instead of pipe messages)
commitf5d7318dd9f12131e8777609a7733db2fc02f636
authorKasper Kopec <kasper@fb.com>
Sat, 5 Mar 2016 07:12:38 +0000 (4 23:12 -0800)
committerHhvm Bot <hhvm-bot-bot@fb.com>
Mon, 7 Mar 2016 18:34:25 +0000 (7 10:34 -0800)
treed6de86bb7b96329d9e7da5b135e5e58a1a4a989a
parent2272241fc51de98f1e45966d5946ae3564bd9525
Use a mutex to synchronize access to shared hashtable (instead of pipe messages)

Summary:Motivation, in addition to int3 comments from D2879026:

- Currently, locking requires sending a message, and this requires having a pipe. We'll want to have this locking happen only when necessary, which will be around the unsafe memory accesses. Those accesses are done via global module, and are usually pretty deep in the code, so passing the pipe there gets pretty ugly. Now locking logic parallels access logic (in being done through a global module).

- Enabling pipe messages to be treated as asynchronous requests queue - I've wanted the find references command to be handled by master process (because it needs to be parallel/is slow anyway/is pretty rare), by sending this request over pipe and getting the result whenever it's ready. But mixing the lock-related-must-wait-for-an-answer messages with those kind of requests doesn't work well.

As for //#ifdef _WIN32// parts - I believe Hack doesn't currently work on Windows anyway, so I just did enough to get hh_shared.c to compile for Flow (where the new functions won't be called), and if anyone will come back to picking the port up, they'll have to fill the TODOs.

Reviewed By: int3

Differential Revision: D2998162

fb-gh-sync-id: a3e83bd4796f656a6278be3a74481cd317aa5de6
shipit-source-id: a3e83bd4796f656a6278be3a74481cd317aa5de6
hphp/hack/src/heap/hh_shared.c
hphp/hack/src/heap/sharedMem.ml
hphp/hack/src/heap/sharedMem.mli
hphp/hack/src/server/ideMain.ml
hphp/hack/src/server/ideProcessMessage.ml
hphp/hack/src/server/serverMain.ml