Nuclide HHVM Debugger - Switch to synthetic thread IDs - 12/N
commit3fbca633b8c260ae817079eaca7d6f2458b8b123
authorEric Bluestein <ericblue@fb.com>
Thu, 4 Jan 2018 02:57:59 +0000 (3 18:57 -0800)
committerHhvm Bot <hhvm-bot@users.noreply.github.com>
Thu, 4 Jan 2018 03:07:57 +0000 (3 19:07 -0800)
treef0d007ec94ee19bd70f23e2592b5f32f402cc30d
parent674366c8e0602b01c2195d5fa2db6857b8651578
Nuclide HHVM Debugger - Switch to synthetic thread IDs - 12/N

Summary:
This diff switches the IDs we present the front end for threads from the actual process thread IDs in HHVM to an artificial int assigned by the debugger engine.

There are a few reasons for needing to do this:

1. Actual thread IDs are uint64_t and the protocol calls for a JavaScript Number, which has a much lower max value.
2. The huge numbers look really strange in the debugger client, they are user visible as "Request ID"
3. This reveals internal implementation details about how HHVM is executing requests that are not relevant / not the user's business
4. Request threads are handled by a thread pool. This means the same request ID is seen exiting and then starting again repeatidly in the UX. This would appear strange to an astutue user, and while Nuclide doesn't care, I'd expect some implementors of the VS Code protocol might trip on this.
5. The logic in client attach that installs the hook on any requests that are already running was actually buggy - it was calling Process::GetThreadID in attachToRequest, which was running on the client connect thread, not the actual request thread.

Reviewed By: rightparen

Differential Revision: D6336882

fbshipit-source-id: 2cf7647b5f91e23f3561bee7a95c2352542f656b
hphp/runtime/ext/vsdebug/debugger.cpp
hphp/runtime/ext/vsdebug/debugger.h