Comments (5)
one could possibly make it backwards compatible by accepting either... (but prefer the array, as in, warn if it isn't one)
from rt-app.
If we want to go in this direction, not only "phases" should be an array but also each phase in "phases" as the events are ordered.
Then, "phases" is optional and events can be directly put in the task node ... which should become a array too.
If we want to move in that direction, we must keep backward compatibility:
- continue to support current syntax
- continue support the fact that "phases" is optional and event can be put directly in "thread1"
from rt-app.
There's an implicit ordering assumption in parsing the json inside rt-app - we build the execution tree as events are delivered, and the parser we use always delivers the events in the order they are present in the source file.
I don't really see much value in changing the syntax, but maybe we could document this expectation?
from rt-app.
yes, it's partially about the design working only accidentally:
- it's "just wrong"(tm), because it says the wrong thing about the data (suggesting the phases are not ordered)
- it's not parsed in rt-app but inside a library that could justifiably change behaviour (use a hash to store the dictionaries)
- when creating the JSON in e. g. python, have to make sure to use an OrderedDict, in order to get "sleep" before "run", for example, but a bit of a hassle if you're generating the config in a language that doesn't have ordered dicts.
there is also at least one actual limitation:
- can't have multiple steps with the same name within the same phase - e. g. {"run": 10, "sleep": 20, "run": 30, "sleep": 40}
from rt-app.
the parser we use always delivers the events in the order they are present in the source file.
Is there anything I missed in the source code backing that ?
Here is what I found for the phases, and it also applies for the events since it's using the same foreach
macro.
From what I can see in parse_task_data()
:
foreach(phases_obj, entry, key, val, idx) {
log_info(PIN "Parsing phase %s", key);
assure_type_is(val, phases_obj, key, json_type_object);
parse_task_phase_data(val, &data->phases[idx], data, opts);
/*
* Uses thread's current sched_data and taskgroup_data
* to detect policy/taskgroup misconfiguration.
*/
check_taskgroup_policy_dep(&data->phases[idx], data);
}
We use this foreach
macro that is defined as:
#define foreach(obj, entry, key, val, idx) \
for ( ({ idx = 0; entry = json_object_get_object(obj)->head;}); \
({ if (entry) { key = (char*)entry->k; \
val = (struct json_object*)entry->v; \
}; \
entry; \
} \
); \
({ entry = entry->next; idx++; }) \
)
So the order is determined by the output of json_object_get_object()
, itself declared as:
JSON_EXPORT struct lh_table *json_object_get_object(const struct json_object *obj);
So the lh_table
structure decides of the order, which is a proper hashtable, which is (indirectly) created by json_object_new_object()
. The hashtable itself is created at:
lh_kchar_table_new(JSON_OBJECT_DEF_HASH_ENTRIES, &json_object_lh_entry_free);
with a hash function for strings.
https://github.com/json-c/json-c/blob/master/json_object.c#L562
New keys are added by the JSON parser to objects using json_object_object_add()
, which does not seem to do anything special to preserve the order:
https://github.com/json-c/json-c/blob/master/json_object.c#L620
EDIT: it does indeed preserve the order of insertion by maintaining a linked list of the items in the hash table:
https://github.com/json-c/json-c/blob/master/linkhash.c#L613
from rt-app.
Related Issues (20)
- Python 3 compatibility HOT 2
- Create hackbench workload with rt-app
- Print in the log file the core used HOT 1
- broken examples HOT 2
- impossible to reset uclamp
- Change in uclamp fails if not accompanied by policy
- uclamp and taskgroup mix issue
- Asymmetrical treatment of "priority" and "policy"
- error with ftrace examples HOT 1
- This isn't an issue rather a question HOT 2
- usage: rt-app <taskset.json> HOT 4
- continue_running confused someone, signal handler behaviour is undefined HOT 7
- Looks like this question is still valid and unanswered. :-)
- Merge GRUB reclaiming
- RTapp fails to run with the right runtime when given a float
- mlockall always applied by default without graceful failure
- rt-app ignores invalid task names
- rtapp execution gives unreliable actual duty cycle HOT 21
- generated gnuplot plot file is wrong
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rt-app.