Hi Chapel Developers -
It came up recently that local { } does not compose well
with library code. By that, I mean that the library code
won't necessarily function when it's in a local block. If
the library code needs to communicate - it will fail if
it's called from within a the local block, but the error
message doesn't necessarily lead directly to the problem.
I believe that the same problem also exists for serial
blocks, but for a different reason. There, the library
code might need to actually create multiple tasks in
order for its algorithm to work. When it tries to synchronize
those tasks, it will probably deadlock if they are not
actually tasks but instead run serially.
I have some questions about this dilemma.
1) Is there already a planned strategy for solving this
problem, possibly by replacing local { } and serial { }
with something else?
2) If we want to keep local { } and serial { } as
performance optimizations, could we provide a way for
library code to assert that it needs communication or
task parallelism? Something like:
proc libraryFnThatCommunicates() {
assertNotInLocalBlock();
...
}
and
proc libraryFnThatSynchronizesSpawnedTasks() {
assertNotInSerialBlock();
...
}
3) Another idea would be to only allow local/serial blocks
to call functions that are marked in some way that
they are compatible with local/serial blocks...
but I think I prefer the assert method.
4) A completely different strategy would be to make
better stack traces for failed tasks, including
tracing through 'on' statements.
Interested in your thoughts,
-michael
------------------------------------------------------------------------------
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
