I have seen in other environments, for example iOS / obj-c UI code, use an
assert type mechanism to ensure that they were running on the main thread.
In these scenarios it was more of a safe-guard rather than dealing with an
intrinsic property of the language (e.g. local or serial).
It seems to me that it would better if the compiler could create this
assert for you via an annotation or keyword added to a function
definition. I don't know what the annotation syntax would be, but perhaps
something like this?
proc remote libFnRemoteWork() { doRemoteWork(); }
which implies:
proc remote libFnRemoteWork() {
assertNotInLocalBlock();
doRemoteWork();
}
this would allow you to have consistent compiler options such as
--no-local-check for scenarios where you don't want it. Also, there may be
different / better ways to enforce this later and everyone would just get
it for free.
now that i think about it, it may also be nice to say a function should
always execute locally:
proc local libFnLocalWork() {}
i'm a big fan of local keyword as it has helped me catch countless implicit
RPC subtleties that would otherwise, silently, created network traffic.
I don't have an opinion on serial as I've not used it much yet.
On Thu, Jun 4, 2015 at 5:45 AM, Michael Ferguson <[email protected]> wrote:
> 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
>
------------------------------------------------------------------------------
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
