More sensible domain id handling; stopping throughput publisher

[eboasson]

This pull request partially addresses two open issues:

• One commit addresses the first issue raised in Three major issues found for Cyclone. #23, by allowing any domain id to be used in dds_create_participant as long as the configuration file doesn't explicitly set a domain id. To accomplish this, the domain id specification in the configuration file now allows the keyword any (also the new default). This doesn't affect any cases that used to work already.
• The other commit addresses the observation in ThroughputPublisher Termination #22 that ^C doesn't work when there is no subscriber. It ignores the termination flag set by the ^C handler while waiting for the subscriber to show up. This fix addresses it by delaying the setting of the handler, until the termination flag is respected.
  The other points raised in these two issues are not addressed.

[eboasson]

@k0ekk0ek, I am pretty sure the one test failure is Criterion hanging in termination. Could you please have a look and let me know if you are happy with this change and, if so, think it reasonable to merge it despite this failure?

[k0ekk0ek]

@eboasson, I agree with the changes. And yes, please merge the changes. We know Criterion sometimes misbehaves (it'll be removed at some point not too far in the future) and I don't see how any of your changes should lead to difficulties during termination.

[eboasson]

Hi Juan, There are various reasons behind it: It is partially historical, inherited from OpenSplice’s DDSI service; It is also in part because in my experience it is often much nicer to set the domain id from the environment instead of programmatically, and as the configuration processing performs environment variable expansion, you can use that; It is in part because the day (hopefully soon) that multiple simultaneous domains are supported, it will allow you to have multiple configurations and pick the one that matches the requested domain id. For the latter bit, chances are that it will change from an id or “any” to a list of ids or “any”, but that’s a mere detail. Also haven’t yet given thought to whether there would be multiple configurations in a single file, or whether there’d be multiple files, &c. First order of business in this is to get the old global variables inherited from OpenSplice’s service out of the way. Best regards, Erik

…

On 25 Jun 2019, at 02:52, Juan Oxoby ***@***.***> wrote: This pull request partially addresses two open issues: One commit addresses the first issue raised in #23 <#23>, by allowing any domain id to be used in dds_create_participant as long as the configuration file doesn't explicitly set a domain id. To accomplish this, the domain id specification in the configuration file now allows the keyword any (also the new default). This doesn't affect any cases that used to work already. What's the reason for having the option of setting the domain id in the config file? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#24?email_source=notifications&email_token=AEBSPRP4N257JPNQS6B7YKTP4FT47A5CNFSM4F3L7DT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYOUG5I#issuecomment-505234293>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEBSPRK37PPPKKYKOGPLWVLP4FT47ANCNFSM4F3L7DTQ>.

[joxoby]

Hi Erik,

Thanks for your answer.

What bugs me about it is that the domain-id is not a parameter of a DDS instance, since a single DDS instance should be able to support simultaneously every domain-id. Having a config option for a default domain-id makes sense, but this value should not have precedence over a domain-id explicitly supplied by the user programmatically when creating a new participant.
Also, multiple configuration sets for different domains in a single DDS instance might create a whole new set of complications without gaining much from it.
Again, I think that the domain-id should be interpreted as a "variable" of an instance instead of as a parameter.

Thank you.

[eboasson]

Hi Juan, I agree with you … and your earlier comment actually did the trick to get me sufficiently annoyed by the current state of affairs to sit down for the unpleasant work of finally eliminating the global variables that today prevent supporting multiple domains simultaneously. So thank you for that! ☺️ With that, where today you effectively set the domain for the entire process when creating the first participant, soon you’ll be allowed to freely specify a domain id when creating a (additional) participant. That’ll incidentally solve the RMW layer’s problem today, where it usually needs to create something before a node has been created, and thus needs to create a participant without knowing the intended domain id, and thereforce locks the entire process to that domain id. For now, the configuration will be chosen based on that domain id — and in the first iteration, that will probably always be the same configuration, parameterised by the domain id. Whether multiple configurations for different domain ids in the end will be worth it is something we’ll have to see. I know of some cases where it would matter given what you can specify today in the configuration, but that’s not to say there do not exist more elegant ways. One step at the time. Regards, Erik

…

On 25 Jun 2019, at 20:48, Juan Oxoby ***@***.***> wrote: Hi Erik, Thanks for your answer. What bugs me about it is that the domain-id is not a parameter of a DDS instance, since a single DDS instance should be able to support simultaneously every domain-id. Having a config option for a default domain-id makes sense, but this value should not have precedence over a domain-id explicitly supplied by the user programmatically when creating a new participant. Also, multiple configuration sets for different domains in a single DDS instance might create a whole new set of complications without gaining much from it. Again, I think that the domain-id should be interpreted as a "variable" of an instance instead of as a parameter. Thank you. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#24?email_source=notifications&email_token=AEBSPRKMEXP4ULTKU5PYGZLP4JR6NA5CNFSM4F3L7DT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYRHAKI#issuecomment-505573417>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEBSPRP3SUC577XDUSHZ3ULP4JR6NANCNFSM4F3L7DTQ>.