On Thu, Oct 12, 2017 at 2:24 AM, Steve Petruzza <[email protected]>
wrote:
> Going back to the channels discussion, how do you know if a channel has
> been already registered or not?
>
> Look at the following code below (running with 2 localities):
> - they create or connect to the same channel name
> - if I introduce a delay in the receiver locality I get the following
> error:
>
> <snip>
>
> int hpx_main(boost::program_options::variables_map& vm){
> std::vector<hpx::naming::id_type> localities =
> hpx::find_all_localities();
>
> int loc_count = 0;
> for(auto loc: localities){
>
> spmd_int_action act;
> hpx::async(act, loc, loc_count);
>
> loc_count++;
> }
> }
>
> <snip>
>
> More in general, when you have many of this channels at scale, do you
> think is better to use a register_as/connect_to mechanism or to pass alle
> the necessary channels to each locality at the beginning when I do the
> initial SPMD spawn?
>
Looking at the code as shown above, it will not scale. The bottleneck is
the linear spawn of `spmd_init_action`. If you operate in a SPMD fashio,
you should really use the "--hpx:run-hpx-main" command line parameter. This
runs hpx_main on each locality and avoids one extra broadcast. If you
indeed require such a startup code, that is spawning from a single, root
locality, you should use hpx::lcos::broadcast.
As of the initial question regarding connecting to vs. distributing GIDs
explicitly. I guess it is a question on how you want to distribute the GIDs
in the first place. By registering a name, you implicitly distribute this
information without explicit message passing. The symbol namespace (the
thing that resolves the name to a GID) does indeed scale. The strings are
usually constant and defined by the application (that is you). As a result,
you save those information distribution messages.
Of course, the problem with the channel going out of scope to early has to
be solved still. It is clearly a synchronization error, that is, the action
exits without waiting on the communicating partner. In your specific case,
connecting on the side of set and registering on the set side would solve
the issue you are seeing.
>
> Thanks,
> Steve
>
>
>
> On 11 Oct 2017, at 14:53, Steve Petruzza <[email protected]> wrote:
>
> Thanks Hartmut, it all makes sense now.
>
>
> On 11 Oct 2017, at 14:51, Hartmut Kaiser <[email protected]> wrote:
>
>
> I think I’ve found a workaround.
>
> If I use a typedef as following:
>
> typedef std::vector<char> vec_char;
>
> HPX_REGISTER_CHANNEL(vec_char);
>
> It works, but if I try to use directly:
> HPX_REGISTER_CHANNEL(std::vector<char>)
>
> this gives me the error I reported before.
> The issue might be in the expansion of the macro HPX_REGISTER_CHANNEL.
>
>
> Yes, that confirms my suspicion. I will have a looks what's going on.
>
>
> Doh! The problem is that the (literal) parameter you give to the macro has
> to conform to the rules of a valid symbol name, i.e. no special characters
> are allowed (no '<', '>', etc.). Sorry, this has to be documented properly
> somewhere, and I forgot to mention it in the first place.
>
> The 'workaround' you propose is the only way to circumvent problems. There
> is nothing we can do about it.
>
> Also, wrt your comment that everything is working if you use
> hpx::lcos::local::channel instead - this is not surprising. The local
> channel type is representing a channel which can be used inside a given
> locality only (no remote operation, just inter-thread/inter-task
> communication), hence its name. Those channels don't require the use of the
> ugly macros, thus there is no problem.
>
> HTH
> Regards Hartmut
> ---------------
> http://boost-spirit.com
> http://stellar.cct.lsu.edu
>
>
>
> Thanks!
> Regards Hartmut
> ---------------
> http://boost-spirit.com
> http://stellar.cct.lsu.edu
>
>
>
> Steve
>
>
>
>
> On 10 Oct 2017, at 18:38, Steve Petruzza <[email protected]> wrote:
>
> Sorry, regarding the version that I am using it is the commit of your
> split_future for vector:
>
> Adding split_future for std::vector
>
> - this fixes #2940
>
> commit 8ecf8197f9fc9d1cd45a7f9ee61a7be07ba26f46
>
> Steve
>
>
>
> On 10 Oct 2017, at 18:33, Steve Petruzza <[email protected]> wrote:
>
> hpx::find_here()
>
>
>
>
>
>
> _______________________________________________
> hpx-users mailing list
> [email protected]
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
>
>
_______________________________________________
hpx-users mailing list
[email protected]
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
