A simpler solution, which we’ve considered in the past but never implemented, would be to take the task ID type out of the implementation-specific definitions and just make it (say) an int64_t in all cases. The only reason I hadn’t already done this already was that it was so far down the list in importance. I wouldn’t mind a bit if someone wanted to take this on …
greg > On Jan 3, 2017, at 7:42 AM, Michael Ferguson <[email protected]> wrote: > > Hi - > > On 1/2/17, 12:46 PM, "sri raj paul" <[email protected]> wrote: > >> Hello, >> >> I am looking at the Chapel tasking-runtime source code. >> >> Each tasking model typedefs “chpl_taskID_t” to its own ID type and >> chpl_task_getId() has a return type of chpl_taskID_t >> The introduction of chpl_taskID_t might be to support multiple low-level >> runtimes. >> >> But in runtime/include/qio/qio.h:212 , Inside struct qio_lock_t , task >> owner’s ID is of type int64_t >> Later in runtime/src/qio/qio.c , inside functions qio_lock() and >> qio_unlock(), task IDs are stored int64_t variables. >> and also compared using binary operators (== , !=) in >> runtime/src/qio/qio.c:103 and 122. >> >> This causes type conversion errors if the underlying tasking model is >> using some ID type that is not compatible with integer. >> The qio files should also use chpl_taskID_t instead if int64_t. > > This change sounds reasonable to me and you could create a PR to do it. > Nonetheless the code that is there should be OK for any task ID that is a > pointer or integer type, > which is all that we have so far. > >> Also binary operators are not applicable to all types and therefore it >> will be better if each tasking model provides an isEqual() api for its ID >> type. > > I'm less certain about this one. > >> We tried this change and noticed that the runtime/src/chpl-visual-debug.c >> type-casts chpl_taskID_t to some integer type while doing printf(). > > Right, chpl-visual-debug.c creates a log file for chplvis to use. The > visualization tool needs to > be able to figure out which events are in which task. I bet that for > chplvis's purposes though, > the "task ID" could be an arbitrary string. > > Could you say more about what the "task ID" you are trying to use > contains? How many bits long is it? > >> >> Again this causes problem for types not compatible with integers. >> So either a custom format specifier for ID should be made or easier >> option is to provide a chpl_taskID_t_to_integer() by each tasking model. > > > As with a custom isEqual(), I'm not sure if we need > chpl_taskID_t_to_integer. Let's talk more about > what you hope to encode in the task ID. > > > Thanks, > > -michael > > > >> Just for testing, the address of chpl_taskID_t can be type casted to an >> integer pointer and then dereferenced, but this will cause loss of >> information. >> >> Thank you >> Sriraj >> >> >> -------------------------------------------------------------------------- >> ---- >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >> _______________________________________________ >> Chapel-developers mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/chapel-developers > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Chapel-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/chapel-developers ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
