The only consequence is that the tkmap would probably map the same topic to a different iid each time one was written, or that a different topic would get mapped to some other iid. The latter would cause the WHC to overwrite the older topic. Actual damage is minimal as it would only result in incomplete topic discovery by OpenSplice. That it is mostly harmless today does not mean it couldn't cause any number of interesting surprises in the future.
Signed-off-by: Erik Boasson <eb@ilities.com>
and that is implied by the x86/x64's memory model ... avoiding the mfence instruction is a significant win
Signed-off-by: Erik Boasson <eb@ilities.com>
simply switching from dds_alloc to os_malloc in alloc_sample removes a redundant memset, which gives 5% improvement in a throughput test (on my laptop); other analogous changes for consistency
Signed-off-by: Erik Boasson <eb@ilities.com>
without this, deleting the last reader/writer that references the topic results in a dangling pointer ... but there is another intriguing solution: erase the topic from the proxy reader/writer when the last matching local one disappears, so that the topic completely disappears. I rather like this second solution, but I am not yet sure of the consequences and the first (implemented one) is such a simple change that fixes a real problem that it is a no-brainer
Signed-off-by: Erik Boasson <eb@ilities.com>
This addresses the deadlock of #41 but leaves another issue open: sequencing of listener invocations on publication/subscription matched events: there is a risk that the "unmatch" even precedes the "match" event from the application perspective, even though it is quite unlike in practice. Various ways of addressing it exist, but it looks like sequencing at the level of the "dds" entities suffers from similar risks. So better to just avoid the deadlock for now.
Signed-off-by: Erik Boasson <eb@ilities.com>
Previously it would fall through and assert in a debug build or return an error in a release build. The behaviour in a release build was almost correct, as the flag means the entity should be completely ignored if the parameter is not understood by the implementation, but I don't believe it should result in a warning — certainly not that claims the parameter list is invalid. A specific return code is now used to indicate a parameter list that was rejected because of this flag, and that suppresses the warning.
Signed-off-by: Erik Boasson <eb@ilities.com>
this is just an intermediate step: firstly, iid-to-key lookup is a linear scan; secondly, the lookup should happen on the RHC or the WHC and not on some internal map to associates key values with instance handles and is independent of entities
Signed-off-by: Erik Boasson <eb@ilities.com>
Make function names more consistent:
* ``dds_topic_{get,set}_filter`` -> ``dds_{get,set}_topic_filter``
* ``dds_{get,set}_enabled_status`` -> ``dds_{get,set}_status_mask``
* ``dds_instance_lookup`` -> ``dds_lookup_instance``
Plus removal of defunct ddsv2.h.
