Clarify meaning of "system process" about debug-adapter-protocol HOT 7 OPEN

so I assume this was a forward-looking change in the event that we ever add internal IDs for processes.

No, some debuggers have internal ids for processes, even if they aren't exposed in DAP. The intent was to say "we don't care about your internal ids, please don't send them" :)

from debug-adapter-protocol.

It means the operating system's process id (as opposed to some internal id from the debugger).

from debug-adapter-protocol.

And a 'non-system process' is trying to talk about some sort of virtual process. Examples: coredump, in-memory snapshot of a process's state, process that represents some sort of remote device, etc.

from debug-adapter-protocol.

Appreciate the clarification 🙂 DAP doesn't have "process IDs", so I assume this was a forward-looking change in the event that we ever add internal IDs for processes.

My clarification wording feels a little clumsy, namely "logical" vs "physical" (is "virtual" vs "physical" better? something else?). Happy for any suggestions:

interface ProcessEvent extends Event {
  event: 'process';

  body: {
    /**
     * The process ID of the debugged process, as assigned by the operating
     * system. This property should be omitted for logical processes that do 
     * not map to physical processes on the machine.
     */
    systemProcessId?: number;

from debug-adapter-protocol.

I don't have the historical context behind this property -- @gregg-miskelly or @roblourens perhaps?

from debug-adapter-protocol.

Oh, I have no idea. VS Code doesn't use it. It kind of sounds like it could be a PID and a "non-system process" would be a process that doesn't represent a real OS process but I don't know what that use-case would be. @isidorn?

from debug-adapter-protocol.

VS Code doesn't look at ProcessEvent at all

from debug-adapter-protocol.