Community
Participate
Working Groups
The RunControl containerSuspended event sends a PC value. E • RunControl • containerSuspended • <string: context ID> • <int: PC> • <string: reason> • <state data> • <array of context IDs> • In what scenario would a container would have a PC value? Is this addressing the case where the event was being sent for one of the contexts (such as a thread or a core) in the container that caused the suspension, and the context ID and PC are pertaining to that context? I think that the specification should allow a null to be sent for the PC for this event. E • RunControl • containerSuspended • <string: context ID> • <PC> • <string: reason> • <state data> • <array of context IDs> • <PC> ⇒ null ⇒ <int: PC value> Unfortunately this specification change would break backwards compatibility. Incidentally, the Java implementation already uses a String for PC value so as to allow null in a few different methods pasted below! (Any particular reason a String was preferred over a BigInteger?) void doneGetState(IToken token, Exception error, boolean suspended, String pc, String reason, Map<String,Object> params); /** * Called when a thread is suspended. * @param context - ID of a context that was suspended. * @param pc - program counter of the context, can be null. * @param reason - human readable description of suspend reason. * @param params - additional, target specific data about suspended context. */ void contextSuspended(String context, String pc, String reason, Map<String,Object> params); /** * Called when target simultaneously suspends multiple threads in a container * (process, core, etc.). * * @param context - ID of a context responsible for the event. It can be container ID or * any one of container children, for example, it can be thread that hit "suspend all" breakpoint. * Client expected to move focus (selection) to this context. * @param pc - program counter of the context. * @param reason - human readable description of suspend reason. * @param params - additional target specific data about suspended context. * @param suspended_ids - full list of all contexts that were suspended. */ void containerSuspended(String context, String pc, String reason, Map<String,Object> params, String[] suspended_ids); --------- Legal Message: I, Sidharth Kodikal, declare that I developed attached code from scratch, without referencing any 3rd party materials except material licensed under the EPL. {I am authorized by my employer to make this contribution under the EPL.}
> In what scenario a container would have a PC value? I have to point out that PC value (and <state data>) are not necessarily properties of a container. They belong to the context that is the first parameter of the event, and this parameter can be null. If the context is null, client should ignore PC and <state data>, which can be 0 and null in such case. Sending PC=null might be better then 0, but it does really makes much difference - clients would ignore it anyway. According to specs: "The message contains context ID and context state data of a context responsible for the event. It can be container ID or any one of container children, for example, it can be thread that hit "suspend all" breakpoint." Normally, you don't want to report a stateless container as "a context responsible for the event". The main purpose of that ID is to be a hint for debugger UI: it suggests which thread to move focus (select) when multiple thread are suspended at same time. Selecting a container is not what most users would expect. If "a context responsible for the event" can not be determined you supposed to send null. Note, that containerSuspended event is just a short form of a sequence of contextSuspended events. If you never send contextSuspended for a container - contextSuspended is not supposed to be send for a stateless container, you should not include container ID into containerSuspended event. If, despite all that, you still want to report a stateless container as "a context responsible for the event", I see two options for PC value: 1. 0 - no need to change specs, clients will ignore the value after checking context property "HasState", which must be false (or not present) in this case; 2. null - need to change specs, clients don't need to look at context properties to know that "HasState" is false. Let me know your preference. > Any particular reason a String was preferred over a BigInteger? Some people want PC to be a string to support exotic cases when PC is not a number, but something like segment and offset. This is still open for discussion.
I'm closing this entry since discussion apears stalled
Moving bugs to new home for IP log.
