Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tcf-dev] Extending TCF Processes service to provide thread creation capability

Hi,

I also think that "start" could be used to start threads, and probably also VxWorks tasks.  Having a separate "createThread" command seems limiting and would in my opinion be better implemented by a separate service.

In the simplest form of start could be used with NULL as working directory, program image file, command line, and environment variables.  In this case a parameter,e.g. as Martin suggested "StartAddress" could be used to indicate where to start the thread, and as Eugene suggested "MemSpaceID" could indicate which process/address space to start the thread in.

I would not reuse program image file to indicate start address, start symbol, etc since that is confusing and limiting.  In fact in some cases it could be useful to  to load extra code, like shared library, kernel modules, etc for the thread to use, so program image file could be used together with "MemSpaceID" and "StartAddress" properties.

Adding "getCapabilities" seems like a good idea.  The capability properties I see needed are "ID" with the context-id for the queried context and "StartParams" with an array of supported parameter names.

BTW, what are the use cases that you have in mind?

My $.02,
Felix

On Jun 19, 2013, at 3:33 PM, "Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx> wrote:

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.
 
On 6/8/2013 6:00 PM, tcf-dev-request@xxxxxxxxxxx wrote:
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
 
_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/tcf-dev



This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.



Back to the top