Pulling this up to the top …
This approach sounds fine to me too. I'd probably call the methods
'chpl_task_idToString' and 'chpl_task_idEquals' but chpl_task_sameIDs
is OK if Greg really wants it to be that way :)
I considered chpl_task_idEquals and ended up not liking it because we’ll be
passing two IDs in and it seemed more natural to call it chpl_task_idsEqual,
which I also wasn’t that fond of. Any of the 3 will work, though — coder’s
choice. :-)
Sriraj, can we rely on you to create a pull request making these
changes? (at least if nobody else chimes in…)
I would envision a total of either 3 or 4 PRs:
* add chpl_task_idEquals() (or whatever) and chpl_task_idToString() to the
existing public tasking implementations
* (optional) the massiveThreads folks add the above to their tasking
implementation (but could also be included in the first PR)
* add the above to the Cray-private muxed tasking implementation (has to be
done by the Chapel core team)
* change to using these two functions in qio, chplvis, and anything else
that needs them
The important thing is to make sure that last one doesn’t happen until all the
ones before have, so that we don’t end up not being able to build the runtime
in some configurations.
By the way, I want the caller of chpl_task_idTostring() to pass a buffer (and
length) to put the string in, instead of allocating it dynamically. I expect
the string will rarely (never?) need to outlive the caller’s activation record,
so let’s avoid the allocation overhead. This probably means we also need the
implementations to define something like a CHPL_TASK_ID_STRING_MAX_LEN
preprocessor value that callers can use to ensure their buffer is big enough
for any legal task ID representation.
greg
On Jan 4, 2017, at 10:27 AM, Michael Ferguson
<[email protected]<mailto:[email protected]>> wrote:
Hi -
On 1/4/17, 11:57 AM, "Greg Titus" <[email protected]<mailto:[email protected]>> wrote:
Actually, given Sriraj’s latest response I’ve come around to the other
point of view.
Let’s separate the issues of the internal and the external task ID
representation. Even if the internal representation is a plain 64-bit
int defined independently from the implementations, defining a
chpl_task_sameIDs() to compare task IDs is a good idea so that the rest
of the code isn’t dependent on that internal type. That’s just good
interface engineering practice.
Then, no matter what the internal representation is, only the
implementations can provide a reasonable chpl_task_idToString()
conversion function to produce the external representation, because only
the implementations can decode or unpack encoded internal IDs. For
example, if the encoded form has 16 high-order bits of node ID and 48
low-order bits of task ID within node, if some ID has node==1 and
task_within_node==2 clearly it’s better to print “1:2” rather than the
raw value “281474976710658" or “0x100000002” an implementation
independent convertor would produce.
Given that we need chpl_task_sameIDs() and chpl_task_idToString() anyway,
I believe we should continue to have the implementations define the task
ID type, so they can use whatever is convenient for them, and then
require them to provide those two functions (and adjust to using those in
qio and chplvis and elsewhere as needed).
This approach sounds fine to me too. I'd probably call the methods
'chpl_task_idToString' and 'chpl_task_idEquals' but chpl_task_sameIDs
is OK if Greg really wants it to be that way :)
Sriraj, can we rely on you to create a pull request making these
changes? (at least if nobody else chimes in...)
-michael
------------------------------------------------------------------------------
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
