Hi Jean-Michel / Eugene,
The discussion below seems stalled, so I’m going to give my 2 cents … and suggest moving the discussion to a bugzilla item for better tracking. You can reference the mailing
list there.
createThread command looks rather redundant. I would prefer an option for "create" command, e.g. MemSpaceID. It would be similar to CLONE_VM option in clone() function.
I guess you're talking about adding an option to "start" command (not "create" command)?
Handling both processes and threads creation with "start" command was effectively our first idea, but we finally changed our mind because we thought that the "start" command interface would become too complicated,
confusing and error-prone:
It doesn’t look too confusing to me, except that the name of the Service (“Processes”) is a bit unfortunate when it’s extended to be more generic. A name like “ContextManager”
would seem more appropriate as it’s getting more generic … but we can probably live with the legacy (and have it documented).
For thread creation, we need to specify the entry point which could be either a symbol name or an hexa/decimal value. To pass this entry point, we could use the existing <string: program image file> argument, but
how would we determine if this argument is a file or symbol name?
Semantics of the extension seem simple to me – without a MemSpaceID you ycan’t give an address/symbol since you don’t have a context for it. With a MemSpaceID you must give an
address/symbol.
For clarification and keeping semantics always identical, it might be better to have the “filename” argument empty for Threads and
specify an additional option argument “startAddress” or “startSymbol” for Threads. I could imagine a situation where even launching a Process you’d give a name and an optional startSymbol other than “main” (just think about WinMain for instance).
Testing file or symbol existence seems heavy, and not 100% reliable as we could have a file with same name than a symbol...
Who should have to test for argument correctness ? It’s opaque to the protocol IMO.
Should we add an option to explicitly indicates that we want to create a thread: "ThreadCreation" : <boolean>.
This seems unnecessary and redundant to me, since the definition of a Thread is a runnable context inside some other address space. But perhaps I’m missing peculiarities of some
specific OS that you’re thinking about ?
Moreover, the list of options would be more complicated to read, as some would apply to both processes & threads creation, while others would apply to only processes, or only threads:
I don’t see a problem with this. One benefit of the “Map Dictionary” for options is its flexibility, which can be leveraged here.
<options>
options consists of a list of options properties.
"Attach" : <boolean> : If true, debugger should be attached to created context.
"AttachChildren" : <boolean> : If true, debugger should be attached to children of created context.
"StopAtEntry" : <boolean> : If true, debugger should break at entry point.
"UseTerminal" : <boolean> : If true, use terminal for IO redirection.
"StackSize" : <int> : Stack size.
"Priority" : <int> : Priority.
"ThreadOptions" <string array> : thread option names selected from "SupportedThreadOptions" returned by Processes getCapabilities.
Process specific options:
"StopAtMain" : <boolean> : If true, debugger should break on main.
"ProcessOptions" <string array> : process option names selected from "SupportedProcessOptions" returned by Processes getCapabilities.
Thread specific options:
"Name" : <string> : Name of thread to create.
"Priority" : <int> : Priority of thread to create.
"StackSize" : <int> : Stack size of thread to create.
Priority and StackSize are already “Common” options.
The “Name” could actually be common too, I just learned yesterday that the name of a process is not necessarily identical to the name of the image file that you’re using to launch
it. Many other services have options applicable only partially, that’s not a problem as long as the same option name always has the same semantics.
I’d want to avoid “modes of operation” where one given option name behaves differently in different scenarios.
I suggest to create Bugzilla for this.
So do I.
Should we create a ProcessesV2?
It appear to be clean extension - I don't see compatibility issues, no need to change service version.
I also wouldn’t create ProcessesV2. Keeping the service version the same, you can continue working with existing value-adds (just think about a logger for instance in a value-add, which redirects stdin / stdout of any created process to an additional log stream).
I suggest you create a bug for follow-up and you contribute your proposed API changes there for further discussion.
Using Gerrit would be best since it allows to comment in-line directly in your code.
Thanks
Martin
